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