Hi to all. Thank Josh for think about me.
The status of my merge review branches is:
* Pointwise branch, have reviewer, tweenk, substitute of fillet/chamfer. this is very important to be merged as soon as posible because is not compatible with old code -never released- https://code.launchpad.net/~inkscape.dev/inkscape/pointwise
* Mirror symmetry, have reviewer, tweenk, its practycaly full reviewed. a one step to 0.92 https://code.launchpad.net/~inkscape.dev/inkscape/mirror-symetry-lpe-improve...
* Branch clip eraser: https://code.launchpad.net/~inkscape.dev/inkscape/clip_eraser Not ended yet but no complex branch, I hope I could get ended at the end of next week. Basicaly is a doctormon idea to add an optional mode to eraser tool to use clip mask and allow erase in all kind of objects.
* Mesh and knot improvements, related to mesh gradients, Not enoght tested and not sure about it yes, better wait to 0.93 https://code.launchpad.net/~inkscape.dev/inkscape/mesh_and_knot_improvements
* Offset, better work than current offset LPE but some crash with asserts in new boolops, maybe is better wait to 0.93 https://code.launchpad.net/~inkscape.dev/inkscape/offset
FearestPoint (2geom) not used jet, can wait to 0.93.
Also there is some patches to merge, the most important to me is the one to convert a item to paths retaining fills, markers and paint order.
I´m outside form my computer till friday night or saturaday so I couldent put the 2 last links jet, maybe tonight can have some time but not sure.
Cheers, Jabier.
El 2016-05-05 9:31, Josh Andler escribió:
0.91 was the first time we had an experimental branch, but I'm not against it again.
I would also like to hear from Jabier if he thinks something is a review away from inclusion this cycle or if he thinks it's better to defer his branches for 0.92.
Cheers, Josh On May 5, 2016 12:15 AM, "Alex Valavanis" <valavanisalex@...400... [9]> wrote:
OK, this all sounds very promising. Unfortunately, I won't be available to join in the IRC meeting tomorrow, but by the sounds of things, we're not awaiting any new urgent feature additions. Can I suggest, therefore, that we move into Feature Freeze as soon as possible, and concentrate on bug fixing ready for release? As in previous cycles, we could start an experimental branch for features that can wait until after 0.92.
AV
On 5 May 2016 at 07:59, Josh Andler <scislac@...400... [1]> wrote:
I've worked with SUV for the past half dozen years or so on
figuring out
release blocker stuff. I'm willing to take it on even if there is
no
interest on SUV's end to help determine such things. I will draft
a release
plan tomorrow morning (as I had previously offered to) and send
it to you
Bryce for your review and edits and I will begin reviewing for
blocker bugs
in the tracker after that.
Cheers, Josh
On May 4, 2016 9:08 PM, "Bryce Harrington"
<bryce@...961... [2]>
wrote:
On Wed, May 04, 2016 at 03:57:51PM +0200, Tavmjong Bah wrote:
On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote:
On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote: > > We should discuss this on Friday's IRC meeting. Friday's meeting is a board meeting isn't it? I thought
developer
decisions like releases were more developer consensus on
mailing list
type things and less board responsibility.
(or is this just convenient discussion space?)
Yes, it is not the board's duty to make developer decisions.
But I
think the board does have the responsibility to aid (and prod)
the
developers to make decisions when needed as well as to support
the
execution of those decisions (e.g. fund a dedicated hackfest).
(it is also a convenient discussion space)
You're both right, and I do agree that having a meeting to get
things
going with the release is a great idea.
Traditionally we've often encouraged non-board-specific
technical
discussions to happen immediately following the board meeting.
What if
we had a short board meeting for say 20-30 min, and then a
second
followup meeting specifically to focus on release coordination discussions?
Sounds like we've crested the hill on the cmake work (we still
need to
do a comparison between the automake-generated dist and the
cmake dist,
to see if we're missing anything important). Once we're
comfortable
with what's in the dist, I can cut an alpha release - possibly
as early
as this weekend. I'm prepared to do a series of (bi-weekly?) pre-releases as we work towards the final release. Next step
would be
to start gathering a list of release blockers and recruit owners
for
getting those items examined; I would love it if someone could
volunteer
to coordinate/manage the release blocker bugfixing work.
Bryce
Find and fix application performance issues faster with
Applications
Manager Applications Manager provides deep performance insights into
multiple
tiers of your business applications. It resolves application problems
quickly and
reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z [3] _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net [4] https://lists.sourceforge.net/lists/listinfo/inkscape-devel [5]
Find and fix application performance issues faster with
Applications Manager
Applications Manager provides deep performance insights into
multiple tiers
of your business applications. It resolves application problems
quickly and
reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z [6] _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net [7] https://lists.sourceforge.net/lists/listinfo/inkscape-devel [8]
Links:
[1] mailto:scislac@...400... [2] mailto:bryce@...961... [3] https://ad.doubleclick.net/ddm/clk/302982198;130105516;z [4] mailto:Inkscape-devel@lists.sourceforge.net [5] https://lists.sourceforge.net/lists/listinfo/inkscape-devel [6] https://ad.doubleclick.net/ddm/clk/302982198;130105516;z [7] mailto:Inkscape-devel@lists.sourceforge.net [8] https://lists.sourceforge.net/lists/listinfo/inkscape-devel [9] mailto:valavanisalex@...400...