Hi all,
Last month we talked a bit about accelerating our releases a bit. Since it's been a tad over a month since the 0.42 release, and feels like now would be a good point to begin the 0.43 release process. Based on prior releases I expect it may take several weeks to a month to go through this release process.
I'd like to propose that we target Sept 1st as our feature freeze point. Does anyone feel strongly that we should wait longer than this?
Bryce
On Fri, 2005-08-26 at 21:12 -0700, Bryce Harrington wrote:
Hi all,
Last month we talked a bit about accelerating our releases a bit. Since it's been a tad over a month since the 0.42 release, and feels like now would be a good point to begin the 0.43 release process. Based on prior releases I expect it may take several weeks to a month to go through this release process.
I'd like to propose that we target Sept 1st as our feature freeze point. Does anyone feel strongly that we should wait longer than this?
Well, this is good to get the changes in from the Summer of Code folk, right?
What else are ppl. working on?
Jon
Hi,
I'd like to propose that we target Sept 1st as our feature freeze point. Does anyone feel strongly that we should wait longer than this?
I think we probably should. It's beta period for both SUSE and Mandriva, so I guess a lot of people are busy with those (I definitely am).
Arpad Biro
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
I'd like to propose that we target Sept 1st as our feature freeze point. Does anyone feel strongly that we should wait longer than this?
Unfortunately I was unable to do most of what I planned to do for this release, due to work load. We definitely have enough stuff to release without my contributions, but some of this stuff is in rather unfinished form AFAIK: Michael's connection tool misses a big part of functionality (as of yesterday, at least), and Aaron's curve dragging is not yet committed, for example. So I think Sep 1st is a bit too abrupt.
Meanwhile only the static rpm is missing for the 0.42.2, and we can make an announcement, at least on the front page.
Does anyone knows if Kees will be able to do static rpms? If not, are there any volunteers?
On Sat, Aug 27, 2005 at 01:08:59PM -0300, bulia byak wrote:
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
I'd like to propose that we target Sept 1st as our feature freeze point. Does anyone feel strongly that we should wait longer than this?
Unfortunately I was unable to do most of what I planned to do for this release, due to work load. We definitely have enough stuff to release without my contributions, but some of this stuff is in rather unfinished form AFAIK: Michael's connection tool misses a big part of functionality (as of yesterday, at least), and Aaron's curve dragging is not yet committed, for example. So I think Sep 1st is a bit too abrupt.
Okay. Sounds like we could probably be okay with a Sept 1st cutoff for 0.43, but given this info let me make a different proposal that might fit these needs better.
During the 0.42 release process someone suggested shifting to making odd releases more development oriented and even releases more stability oriented. I think that is a good idea, and have an idea how we could put this into practice:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores. So instead of a long feature freeze where we fix bugs, we have a "feature burn" where we try to implement a lot of little, easy features that folks have requested. We'd still have a hard freeze and so forth to ensure that the release isn't going to crash or whatever, but our focus would be more on completing feature work than on stabilization.
Besides giving everyone more time to finish up whatever features they're currently working on, I think this process would be worthwhile for encouraging people to get involved in development work.
I bet there are a bunch of RFE's in the tracker that are already implemented, but just haven't been reviewed and closed. We can include all of those in the scoring, as a way to encourage going through the RFE tracker and updating stuff. I think it would also be worthwhile for encouraging people to implement features that otherwise might not get attention.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
Meanwhile only the static rpm is missing for the 0.42.2, and we can make an announcement, at least on the front page.
I've done this. I wasn't able to find where the release notes are for this release, though. Also, it looks like the downloads page will need updating. I'd be happy to update the news if someone can take care of these two things. Rejon, once these two things are done, would you be willing to put out all the announcements for it?
Does anyone knows if Kees will be able to do static rpms? If not, are there any volunteers?
Yes, I spoke to him about RPMs after the last release. He said he will no longer do static RPMs. I think he feels that they cause more problems than they solve. I don't completely agree, but I see his point. Certainly I think Inkscape is an important enough project these days that we could shift more of the packaging responsibility to the distros if we wanted. Otherwise, I think he's documented the process well enough that someone else could take over this duty.
(Fwiw, Kees seems to enjoy solving thorny problems, but he seems to prefer handing the processes off to others to maintain, so he can go on to new more interesting puzzles.)
Bryce
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores.
This may be a good idea, but consider that a feature needs much more time to be done well, on average, than a bug. A quick bug fix is good, but a "quick feature" is not always so. I don't think we have a lot of "easy" ones in the tracker anyway.
I bet there are a bunch of RFE's in the tracker that are already implemented, but just haven't been reviewed and closed.
From time to time I do a review and close such ones. Of course there
may be some left.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
I think that's too high. Unless we count everything starting from 0.42. Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
Meanwhile only the static rpm is missing for the 0.42.2, and we can make an announcement, at least on the front page.
I've done this.
Thanks.
I wasn't able to find where the release notes are for this release, though.
They're not on the web, only in the tarball. It's just 0.42 relnotes with a few bugfixes added at the end.
Does anyone knows if Kees will be able to do static rpms? If not, are there any volunteers?
Yes, I spoke to him about RPMs after the last release. He said he will no longer do static RPMs. I think he feels that they cause more problems than they solve. I don't completely agree, but I see his point.
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
Certainly I think Inkscape is an important enough project these days that we could shift more of the packaging responsibility to the distros if we wanted. Otherwise, I think he's documented the process well enough that someone else could take over this duty.
There's at least one bug report whose reporter is waiting for the static rpm to test the fix. So I think we shouild keep providing them, if only for consistency. Volunteers?
On Saturday 27 August 2005 23:23, bulia byak wrote:
Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
How about judging them by how much of a "standard feature" they are across similar apps, and by how much functionality they add that other features could be built on top of?
On Saturday 27 August 2005 23:29, Lee Braiden wrote:
How about judging them by how much of a "standard feature" they are across similar apps, and by how much functionality they add that other features could be built on top of?
Oh, I guess it might help to factor in how much a certain feature would help other FLOSS projects, or the FLOSS community in general. Obviously the number of people crying out for that feature matters too ;)
On Sat, Aug 27, 2005 at 11:29:03PM +0100, Lee Braiden wrote:
On Saturday 27 August 2005 23:23, bulia byak wrote:
Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
How about judging them by how much of a "standard feature" they are across similar apps, and by how much functionality they add that other features could be built on top of?
That's a good idea; we could also rank them based on whether they implement something which is required for compliance to one of the SVG specs.
Bryce
On Sat, Aug 27, 2005 at 07:23:35PM -0300, bulia byak wrote:
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores.
This may be a good idea, but consider that a feature needs much more time to be done well, on average, than a bug. A quick bug fix is good, but a "quick feature" is not always so. I don't think we have a lot of "easy" ones in the tracker anyway.
True, although since we've mined the bug tracker pretty heavily of the easy bugs over the past several releases, but haven't done that at all for the RFE tracker, I suspect for this first time through we may find more quick features than we'd find otherwise.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
I think that's too high. Unless we count everything starting from 0.42.
Sure, I can start the counting from the 0.42 release. I set the goal high because while I know you've been good at checking and closing features, my bet is that there are ones you've missed, and I bet we may be able to get a lot of points just from those.
Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
Yes, I've noticed this. I asked Alan, and he's volunteered to help with this tomorrow.
It's a good question about how to decide how to prioritize them. Offhand, I think RFEs that a lot of users want would score higher. RFEs that augment existing functionality would score higher than ones that require extensive new development work. Beyond that, I think RFE scoring is going to be fairly subjective no matter how we approach it; perhaps we should just accept that the scores will be a bit arbitrary initially, and maybe as we go through the process we'll get a better opinion of how they should be scored, and adjust accordingly.
Does anyone knows if Kees will be able to do static rpms? If not, are there any volunteers?
Yes, I spoke to him about RPMs after the last release. He said he will no longer do static RPMs. I think he feels that they cause more problems than they solve. I don't completely agree, but I see his point.
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
He has the same opinion about autopackage, but he and I have agreed to disagree there (I think autopackage is a great solution, I think he thinks that it's too much of a crutch and that things should be better addressed by the distro itself.) I'll try to get him to post his thoughts about this (I'm not sure he's following inkscape-devel very closely anymore.)
Bryce
On Sat, 27 Aug 2005, Bryce Harrington wrote:
Date: Sat, 27 Aug 2005 16:02:29 -0700 From: Bryce Harrington <bryce@...260...> To: bulia byak <buliabyak@...400...> Cc: Bryce Harrington <bryce@...260...>, inkscape-devel@...6... Subject: Re: [Inkscape-devel] Inkscape 0.43
On Sat, Aug 27, 2005 at 07:23:35PM -0300, bulia byak wrote:
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores.
This may be a good idea, but consider that a feature needs much more time to be done well, on average, than a bug. A quick bug fix is good, but a "quick feature" is not always so. I don't think we have a lot of "easy" ones in the tracker anyway.
True, although since we've mined the bug tracker pretty heavily of the easy bugs over the past several releases, but haven't done that at all for the RFE tracker, I suspect for this first time through we may find more quick features than we'd find otherwise.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
I think that's too high. Unless we count everything starting from 0.42.
Sure, I can start the counting from the 0.42 release. I set the goal high because while I know you've been good at checking and closing features, my bet is that there are ones you've missed, and I bet we may be able to get a lot of points just from those.
Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
Yes, I've noticed this. I asked Alan, and he's volunteered to help with this tomorrow.
Spent most of the afternoon trawling through the Inkscape requests.
Even if you are not interested in triaging bugs/requests it would be very useful if everyone read through the reports more often. Many reports are terribly vague and all too often ask for a very specific feature but with no mention of what the problem might actually be.
For this reason I targetted bugs marked as "nobody" and went through some of them. I did a lot of marking them down, anonymous bugs with out adequate explanations do not deserve high priority.
I increased the priority some reports which I believed were relatively simple or already planned and possible even fixed already.
There are silly amounts of duplicate reports requesting support for $FILE-FORMAT and we need some way to discourage people from posting more of these. And people requesting ABC XYZ and 123 all in the same report is horribly annoying too.
I'm sure there are more than a few reports which could be consolidated and perhaps developers could put things on the roadmap.
I have some thoughts about the need to allow third party shape tools as extensions but I dont really have time to discuss it, but the short version is Inkscape cannot possible support all the things being requested of it and there is a strong tendancy for people to suggest features from Dia/Visio/Xfig and the other old unix application they know but would like an update of but although these features might be nice to have the are something of a tangent to what I think Inkscape is really about and that is giving artists a tool to use. (Technical drawing is already quite well catered for.)
It's a good question about how to decide how to prioritize them. Offhand, I think RFEs that a lot of users want would score higher. RFEs that augment existing functionality would score higher than ones that require extensive new development work. Beyond that, I think RFE scoring is going to be fairly subjective no matter how we approach it; perhaps we should just accept that the scores will be a bit arbitrary initially, and maybe as we go through the process we'll get a better opinion of how they should be scored, and adjust accordingly.
It helps if people comment if they change the priority as it is hard to tell otherwise what is happening.
I'm tired hungry and I'm going home.
- Alan
On Sat, 27 Aug 2005 19:23:35 -0300, bulia byak wrote:
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
That may be because they're downloaded more often (2518 downloads of 0.42 autopackage vs 853 static rpms).
RPMs just aren't capable of dealing with the mess that Linux has become, really, the format isn't flexible enough. It'd be great if Kees could help out with the Inkscape autopackages as they meet the same need but more people are working on it. Kees? Are you still around?
thanks -mike
On 8/27/05, Mike Hearn <mike@...869...> wrote:
That may be because they're downloaded more often (2518 downloads of 0.42 autopackage vs 853 static rpms).
Hmm, but for 0.41 the numbers are quite different: 17k rpms / 5k autopackages. I wonder why such difference in ratios might be.
On Sat, 27 Aug 2005 21:15:11 -0300, bulia byak wrote:
Hmm, but for 0.41 the numbers are quite different: 17k rpms / 5k autopackages. I wonder why such difference in ratios might be.
Yes, I noticed that too. I'm not sure what's going on there - perhaps it's just that these days more people are familiar with the format? Autopackage only came out in April so RPM has huge mindshare compared with it, but it's growing in the non-technical end user community rapidly.
thanks -mike
Mike Hearn wrote:
On Sat, 27 Aug 2005 19:23:35 -0300, bulia byak wrote:
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
That may be because they're downloaded more often (2518 downloads of 0.42 autopackage vs 853 static rpms).
I'd like to propose that the bugs were caused by letting a newbie make the packages. :) They'll get better.
Aaron Spike
On Sun, Aug 28, 2005 at 01:08:09AM +0100, Mike Hearn wrote:
RPMs just aren't capable of dealing with the mess that Linux has become, really, the format isn't flexible enough. It'd be great if Kees could help out with the Inkscape autopackages as they meet the same need but more people are working on it. Kees? Are you still around?
Yup! I just read the list in fits-and-starts. :)
I'd be happy to help out with the autopackage builds. I'm just not sure what is needed from me. :)
On Sun, 28 Aug 2005 08:35:20 -0700, Kees Cook wrote:
I'd be happy to help out with the autopackage builds. I'm just not sure what is needed from me. :)
Well for now, not much, but the more developers who can do it the better as that way if Aaron goes on holiday or whatever people can still do releases :)
Long term, most of the enhancements I've got in mind need to wait until we get the new autopackage version out. I'd like to get Inkscape using some weak linking so we can enable every feature without adding lots of required dependencies, and getting some easy way to browse for/install extensions would also be good.
It'd also be nice if the Inkscape download page detected your OS based on User Agent string and showed the user only the relevant packages.
thanks -mike
On Sun, Aug 28, 2005 at 06:16:55PM +0100, Mike Hearn wrote:
It'd also be nice if the Inkscape download page detected your OS based on User Agent string and showed the user only the relevant packages.
Ooh, yeah, or at least moved your selection to the top.
Can this be done with with Javascript/ajax? That way the page can remain a "static" download.
Kees Cook wrote:
On Sun, Aug 28, 2005 at 06:16:55PM +0100, Mike Hearn wrote:
It'd also be nice if the Inkscape download page detected your OS based on User Agent string and showed the user only the relevant packages.
Ooh, yeah, or at least moved your selection to the top.
Yeah showing only relevant downloads woudl be terribly inconvenient for people like Mike who only have an internet connection with one platform. But highlighting relevant downloads is an great idea.
Can this be done with with Javascript/ajax? That way the page can remain a "static" download.
Can't javascript do everything? :)
Aaron Spike
The model for extensions I like is eclipse extensions. Imagine the same thing for inkscape extensions. Would take a bit of work to change the way linking is done, yes. Of course a DOM tree would also improve extension functionality ...
Mike Hearn wrote:
On Sun, 28 Aug 2005 08:35:20 -0700, Kees Cook wrote:
I'd be happy to help out with the autopackage builds. I'm just not sure what is needed from me. :)
Well for now, not much, but the more developers who can do it the better as that way if Aaron goes on holiday or whatever people can still do releases :)
Long term, most of the enhancements I've got in mind need to wait until we get the new autopackage version out. I'd like to get Inkscape using some weak linking so we can enable every feature without adding lots of required dependencies, and getting some easy way to browse for/install extensions would also be good.
It'd also be nice if the Inkscape download page detected your OS based on User Agent string and showed the user only the relevant packages.
thanks -mike
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
inkblotter wrote:
The model for extensions I like is eclipse extensions. Imagine the same thing for inkscape extensions. Would take a bit of work to change the way linking is done, yes. Of course a DOM tree would also improve extension functionality ...
I have no intention of becoming a "framework". I realize that it is very cool from the CS perspective, but I think the Firefox taught us how the the Mozilla platform was cool -- but a limited scope helps in many cases.
Sorry if I over-reacted, but the "Eclipse-like" term is very scary to me.
--Ted
On Sat, Aug 27, 2005 at 07:23:35PM -0300, bulia byak wrote:
Yes, I spoke to him about RPMs after the last release. He said he will no longer do static RPMs. I think he feels that they cause more problems than they solve. I don't completely agree, but I see his point.
I'm out of my depth here, but my impression was that they worked relatively well. I think even autopackage had more bugs reported than static rpms.
My issue is that I have no way to trouble-shoot the static RPMs. (And it's very time-consuming to build the static libraries.) I'm building them for an RPM-based system on my Debian Unstable box, which seems rather wonky to begin with. I can't even _install_ what I build to test it. :P And now with my recent change to/back from Ubuntu, I really don't trust my system at all. It has some pretty strange behaviors, which I think are due to various library versions being installed.
What I'd like to see is people building distro-specific RPMs. We include a spec file in the tar.gz file, so it's insanely easy to do. If someone plans to run Inkscape on their distro, it's just a matter of doing:
rpmbuild -ta inkscape-VER.tar.gz
And then they can upload the resulting RPM. I think this makes much more sense than the static RPM, which gets people's hopes up and then they run into weird GTK version issues. If libgc is an issue, maybe we can help out that project by trying to get them to include a spec file in their tar.gz too.
Also, there are many fewer downloads of the static RPMs compared to the autopackage bundle. I'd rather urge people to use autopackage, since it's got willing maintainers, a scripted build system, etc.
I know the static RPM has been useful in the past, but I really want to spend my time on Inkscape doing other stuff. :)
On Sat, 2005-08-27 at 19:23 -0300, bulia byak wrote:
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores.
This may be a good idea, but consider that a feature needs much more time to be done well, on average, than a bug. A quick bug fix is good, but a "quick feature" is not always so. I don't think we have a lot of "easy" ones in the tracker anyway.
I agree. We have enough severe problems from quick feature hacks in the codebase already. Features are definitely one of those things that NEED to be finished at a natural pace, done _when they're ready_.
Combining that with not setting a bug-fixing goal is just a recipe for major disaster.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
I think that's too high. Unless we count everything starting from 0.42. Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
Way, way too high. Bug fix and feature work are inherently different. Bug fixes, we're revisiting familiar old territory. Feature work is more exploratory.
-mental
On Sun, Aug 28, 2005 at 02:21:03PM -0400, MenTaLguY wrote:
On Sat, 2005-08-27 at 19:23 -0300, bulia byak wrote:
On 8/27/05, Bryce Harrington <bryce@...260...> wrote:
For even releases, we use the tallied bug counts like we've done before, but for odd releases (starting with 0.43), we instead count RFE scores.
This may be a good idea, but consider that a feature needs much more time to be done well, on average, than a bug. A quick bug fix is good, but a "quick feature" is not always so. I don't think we have a lot of "easy" ones in the tracker anyway.
I agree. We have enough severe problems from quick feature hacks in the codebase already. Features are definitely one of those things that NEED to be finished at a natural pace, done _when they're ready_.
Combining that with not setting a bug-fixing goal is just a recipe for major disaster.
You may be right, and this is the main reservation I had for proposing this before. But on the other hand, it could possibly work out quite well. We have faced similar risk of introducing new bugs from doing quick bug fixing, yet in practice it has proven well worth the risk. I think it'd be interesting to try it with features as well; if it turns out to cause too many problems, of course we wouldn't do it again.
What I suspect is that, like bug fixes, there are certain features that receive the bulk of the developer attention because they scratch the developer's personal itches or their own development plans, but others which haven't fit in with that process, that this approach would address more directly.
Knowing how good the Inkscape team is at knocking out features, I think we could set our goal at 400 points worth of features.
I think that's too high. Unless we count everything starting from 0.42. Also most RFEs are unprioritized at 5 (and unlike bugs, how are we to prioritize them - by difficulty? by importance?)
Way, way too high. Bug fix and feature work are inherently different. Bug fixes, we're revisiting familiar old territory. Feature work is more exploratory.
Okay, what if we made it 100 points counting from now, just to try this new concept out? That'd work out to something like 10-20 features, which shouldn't be too risky but would be enough to demonstrate or falsify the idea in general.
If you think that the bug-fixing goal is important, perhaps we could follow the 100 points of rfe's with 100 points of bug fixes or something? (Or would that be too complicated?)
Bryce
Quoting Bryce Harrington <bryce@...260...>:
We have faced similar risk of introducing new bugs from doing quick bug fixing, yet in practice it has proven well worth the risk.
I don't know ... whatever the relative levels of risk, the risks are qualitatively different. With intensive feature work you have to be concerned with the architectural quality of the new code.
Since we don't have a developed design review process, most of the design review happens through informal mentoring by e.g. peter, JonCruz (EEEEEK), bulia and myself. I'm partly concerned that we might not be able to keep up.
All that aside, my other concern is that the odd-numbered releases are necessarily going to be buggier if we take this alternate feature/bug release approach. But I suspect that MOST users won't get the even/odd distinction and a lot will get burned. Many users don't fully grasp version numbering as it is...
What I suspect is that, like bug fixes, there are certain features that receive the bulk of the developer attention because they scratch the developer's personal itches or their own development plans, but others which haven't fit in with that process, that this approach would address more directly.
I think that's true.
Okay, what if we made it 100 points counting from now, just to try this new concept out? That'd work out to something like 10-20 features, which shouldn't be too risky but would be enough to demonstrate or falsify the idea in general.
If you think that the bug-fixing goal is important, perhaps we could follow the 100 points of rfe's with 100 points of bug fixes or something? (Or would that be too complicated?)
That might work. Ideally there would be a cooldown period between the feature and bug phases, so we would have a chance to catch and fix bugs in the newly implemented features.
-mental
participants (12)
-
unknown＠example.com -
Alan Horkan -
Arpad Biro -
Bryce Harrington -
bulia byak -
inkblotter -
Jon Phillips -
Kees Cook -
Lee Braiden -
MenTaLguY -
Mike Hearn -
Ted Gould