done in a short enough amount of time. I have helped a bit with the statusbar work; I completed as much as I knew to do and need input for what to do next.
Bug 945735 still stands, and this is what matters here.
Also I'll need time to document the major new things in tutorials. This
also
needs time. And I want to do more redrawing cursors and icons, which is cosmetics but also important.
If there are people interested in / able to help with this work, would it be something you could farm out to them?
If someone comes up with something good, sure, I'll say thank you :) Otherwise I think it will just take me as much time to explain what I want to see as to actually do it.
We do have nightly autopackages posted at http://autopackage.org. If people could use that it would kill two birds - first since then we don't have to set up another nightly autobuild process yet, second so we can get some additional testing of autopackage itself. I'll take the task of encouraging people to use this approach.
That's good if it works. I didn't know about it. I think it needs more advertising.
If I recall correctly, the issues that caused the need for the .1 release were due to insufficient change control; non-trivial code changes were being checked in at the last minute, and one or two of these changes introduced serious bugs. So I agree we should announce our unofficial betas earlier and wider, but I think to prevent the causes of the .1 release last time what we really need is a firmer code freeze especially in the last couple days prior to release. What do you think?
Tighter freeze would be good but difficult as you know :) And anyway wider testing could make these last-minute changes unnecessary by uncovering the problems eariler.
_________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Sat, 19 Jun 2004, bulia byak wrote:
done in a short enough amount of time. I have helped a bit with the statusbar work; I completed as much as I knew to do and need input for what to do next.
Bug 945735 still stands, and this is what matters here.
Okay, thanks.
Also I'll need time to document the major new things in tutorials. This
also
needs time. And I want to do more redrawing cursors and icons, which is cosmetics but also important.
If there are people interested in / able to help with this work, would it be something you could farm out to them?
If someone comes up with something good, sure, I'll say thank you :) Otherwise I think it will just take me as much time to explain what I want to see as to actually do it.
Okay, sounds good. I do know we have several artists around, so maybe one of them will be interested in having a shot.
By the way, Alan has produced a collection of stock gradients, that we're going to try to package as part of openclipart (as opposed to bulking up the Inkscape tarball.) These will get installed to a directory somewhere in the /usr/share/. Is it possible to inform Inkscape of the location and identity of these gradients?
We do have nightly autopackages posted at http://autopackage.org. If people could use that it would kill two birds - first since then we don't have to set up another nightly autobuild process yet, second so we can get some additional testing of autopackage itself. I'll take the task of encouraging people to use this approach.
That's good if it works. I didn't know about it. I think it needs more advertising.
I spent some time testing it and playing with it. It works very well when compared with the usual RPM issues of finding/downloading various dependencies. I think it will help us a lot, especially given the new dependencies we've introduced recently, since it takes care of that for the user fairly seemlessly.
I mentioned the autopackage capability in the article posted to OSNews, and will continue to raise awareness of it as part of this release process.
If I recall correctly, the issues that caused the need for the .1 release were due to insufficient change control; non-trivial code changes were being checked in at the last minute, and one or two of these changes introduced serious bugs. So I agree we should announce our unofficial betas earlier and wider, but I think to prevent the causes of the .1 release last time what we really need is a firmer code freeze especially in the last couple days prior to release. What do you think?
Tighter freeze would be good but difficult as you know :) And anyway wider testing could make these last-minute changes unnecessary by uncovering the problems eariler.
Very true. I've been investigating ideas for attaining tighter freezes since that release.
An issue is that we can publish a beta release for testing, get lots of testing input, but meanwhile developers will be adding bug fixes or even new code to the release branch. Ideally, betatesters would update frequently and re-test, but realistically I think we'll get at most one or two cycles of testing out of people.
In the lucky situation that the beta testing turns up no issues, then in theory there'll be no changes to add to the code, and we could release the beta version / release candidate as-is. More realistically, some changes will need to be made, and the risk is that those changes (or other last minute development that slips in) may introduce new bugs.
If we want to be very aggressive, one option is to temporarily turn off CVS commit for the inkscape module for all but one person who would serve as Change Control during the last couple days of the freeze.
A less intense but similar option would be to have someone just closely track the cvs log for the branch to make sure no untested changes are added.
A different but perhaps more manageable option would be to produce release candidates for each bug-test cycle and require that at least N people give thumbs up on it; if we get all the thumbs up, it's releaseable, else we fix issues and produce a new release candidate, and cycle. The downside to this approach is that it may require a longer feature freeze period than the other two options.
What do you think?
Bryce
participants (2)
-
Bryce Harrington -
bulia byak