Go for the low-hanging fruit. Do whatever work is easiest that can roll into
new releases. If GEGL is toughest, leave that until 2nd, and do the GDK stuff
first. Do whatever you have the strongest team for.
___
Gimp-developer mailing list
Gimp-develope
A change in file formats should be postponed until a bump in the major
version number takes place (per GNU coding standards?). But my
proposal of adding parasites containing layer group meta-data to files
saved in the current XCF standard is indeed merely an interim
solution, permitting tim
On 10/26/07, saulgoode wrote:
> Finally, there should be an effort to maintain integrity of the XCF
> file format by converting between the core implementation of layer
> groups and parasites attached to drawables during saves and loads of
> XCF files (older GIMP versions would read the files but
Regarding the process of developing a roadmap, I think this mailing
list should be where proposals are made and commented upon (there has
already been some nice commentary in this thread). The "main" GIMP
developers should fairly rapidly be able to come to a decision about
the roadmap (thro
The things can be visually organized like the Inkscape does:
http://wiki.inkscape.org/wiki/index.php/Roadmap . As I think, the
roadmap at their site is much late to the current features implemented,
but the whole framework represents the picture.
Although there can be something like preliminary
Hi,
On Thu, 2007-10-25 at 07:35 -0700, Valerie VK wrote:
> On roadmaps: could enhancement requests be grouped by category somewhere?
Bugzilla has categories and we use them.
> After that, a target can be set for individual features ("2.6,"
> "undefined").
We also already use the milestone fea
> So, an important decision must be taken, imo. Plan the 2.6 version as a
> "new core" version (with important improvements in the technical area,
> but maybe not that visible for the final users), or a "new features"
> version. If this isn't defined, there is a risk to fall in a long
> develop
> What do you think?
>
I think it's a great idea to have shorter deveopment cycles. It looks
like the project is more active and alive.
I've heard a lot of people saying that gimp was almost dead, while I was
testing 2.3.x series almost monthly. But people tend to think that the
activity of
Gimp 2.4 is great!
On roadmaps: could enhancement requests be grouped by category somewhere?
Going through the list of enhancement proposals in Bugzilla is rather
awkward to say the least.
I do like how some programs have used a wiki, like Firefox 3 and Inkscape.
Eventually, for Gimp, each wiki
On 10/24/07, Sven Neumann <[EMAIL PROTECTED]> wrote:
[...]
> IMO it would be best if people proposed features here so that they can
> be discussed on the list. We should then collect these proposals
> somewhere and try to decide on milestones for them later. It would
> probably help if we try to be
Sven Neumann wrote:
> Hi,
>
> so far we didn't have a well-defined development roadmap. I would like
> to propose that this is changed for GIMP 2.6 and beyond. Hopefully this
> can help to acomplish two goals:
>
> - GIMP 2.6 should not take too long to develop
> - we will get more developers
>
>
11 matches
Mail list logo
