On Tue, Sep 10, 2013 at 7:39 AM, Martin Owens <doctormo@...400...> wrote:
That's some cynicism Josh. We know that Inkscape's woe is not in the /want/ of people. It's possible developers have a bounty of untapped unpaid time lurking somewhere, but without more upbeat go-getting, positive "WE CAN DO THIS" rallying cries from the leadership... what are you expecting?
I've done a decade of cheerleading for the project. I've been one of the most upbeat, positive, and thankful people to support our developers. Ask Johan, ask Felipe, ask John Smith, ask Krzysztof, ask any number of people who have been around for a while. That said, it's easy to do that when people are energized and excited to work on things. Adding features is fun, fixing bugs is tedious and often a complete pain. For the past handful of releases, getting things locked down was a serious chore... that's not a blame thing, it's just how it has happened.
You, Bryce, Jazzy, Cruz or bbyak, we only need one to push a release forward from the project leadership. But we need all our leaders/administrators to be upbeat, even in the face of crushing economic reality and bad prior experiences.
Well, if the saying "Lead, follow, or get out of the way" applies here, then maybe it's time for me to just get out of the way. I have some rather major things going on in my family currently, so I definitely don't have the ability to pretend to be upbeat about this.
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
This proposition already defeats the purpose. Dating something that is knowingly open-ended is the same as having no date if people tend to procrastinate or don't have a lot of free time.
Although that's harder to enforce with our trunk committing policy, it should be possible to ask feature writers to help fix bugs.
I completely agree. In fact, in a perfect world the feature authors would really have the time and ability to do that.
Don't feel bad about that. That's more likely economics, not a lack of commitment. You talk like someone who's given up already, carrying millstones of previous attempts to do things. Things can still get done, but our leaders must be fearless and quite possibly blissfully ignorant of their past failures. ;-)
I know it's not your intention, but I'm really starting to get the feeling that I just need to not be involved anymore. I can't ignore reality. I can't be ignorant of a past in which I was greatly invested. I definitely haven't given up, but I don't know how to be motivated about this right now if I don't see those bugs getting worked on in a gangbusters fashion. It would be much more motivating if we didn't carry blockers for so long. Perhaps we try to have a new policy for the next dev cycle where no new features can be committed to trunk if a blocker has existed for X amount of time.
Unless we change our policy, we can't release without bringing them in-tree until 2017.
Change of policy it is then, what's the process?
Propose the change to the devel list and if there is a majority consensus, we go with the will of the devs. I do want to say though, bringing a copy of cairo & pixman for a few years isn't ideal, but it doesn't require a change in policy.
We can improve developer's prospects on older releases by having branches, solid instructions, and/or scripting to set up the required code in the right places. Waiting for 2017 is silly.
It is silly and I never proposed that we do that. This is a decent alternative to bringing those libs in-tree imho... but still probably more complicated than us just maintaining copies of the libs in-tree.
Cheers, Josh