I'd be very reluctant to see cairo & pixman brought in tree. My experience with "unforking" GDL suggest that this could cause major maintenance headaches down the line. I think that something like the following approach would be a nicer solution:
== develpment/testing ==
1. Bump dependency versions in configure.ac etc to the required (unstable) versions of Cairo/pixman. Mark bugs as "Fix committed" 2. Create a devlibs branch with a suitable (unstable) Cairo/pixman versions 3. Create a dependency on a daily build of Cairo/pixman in the PPA
...it's then up to individual developers to install their own unstable development libs rather than it being our problem to keep it in trunk. Early adopters and beta testers will be able to continue using the PPA without having to compile from source (or know/understand what has changed).
== pre-release ==
4. Wait for suitable *stable* versions of Cairo/pixman to be released 5. Bump devlibs trunk versions of libraries 6. Kill the unstable devlibs fork 7. Bump PPA Build-Depends version in debian/control and drop dependency on daily Cairo builds 8. Test thoroughly
In any case, I don't think we should go ahead with the 0.49 release until all the dependencies are stable. If that means a longer wait, I'm fine with that!
AV
On 10 September 2013 21:42, Guillermo Espertino (Gez) <gespertino@...400...> wrote:
El 10/09/13 15:47, Jabiertxo Arraiza Cenoz escribió:
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier: Paying for new features is always a problem. It could demotivate the creation of less popular features. It's also unfair, because if some developer gets paid for a new feature, why not all of them? And getting money for all the people involved in a non-commercial project is really a problem.
I proposed the idea of a crowdfunding campaign to cover the less sexy tasks because:
- Those task already exist, and in some cases they block the advance of
the project.
- They can be a source of stress and demotivation in developers. They
pile up, nobody does them, and instead of focusing on new features (which can be a more rewarding job) devs have to address demands of users ranting because X thing doesn't work.
- Did I mention nobody wants to do it?
I bet that several developers wouldn't mind if somebody gets money for that, as long as sombody gets rid of those longstanding, annoying bugs.
Inkscape has a bugtracker with lots of detailed bug reports. The importance of those bugs has been more or less agreed by core developers. Some of those bugs are blocking a release. It wouldn't be difficult to come up with a list or priorities, set a price tag for different importance/complexity bugs and set a fundraising goal.
Of course, IF somebody qualified wants to do the job.
Gez
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel