(I mistakenly sent this to Bryce privately before; sharing to all recipients now)

I understand the dilemma with switching build system, especially when it's such a feature-rich thing as the old one, and the whole Inkscape project depends on it's reliability. That's the immediate problem for 0.92.

But on the other, more general challenge to release speed you are lifting - "What causes the delays are unfinished work and bugs, and needing to
verify that we are indeed stable enough to release." I think the "Ubuntu way" may help: just set a fixed dates for released, so everyone has dates to relate to. (As you know Ubuntu has the idea of feature release in autumn, bugfix release in spring; I don't know how that translates to Inkscape release culture) 

It would require a "dev branch" that's highly unstable, aswell as a more stable "ready for release" branch which includes those features/bugs that's been verified good enough to be included in next release.

Sketch of what I mean: http://i.imgur.com/Mt7gDng.png




Mvh


/Olof
-----------------
3-5-åriga småttingar i närheten?
Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android.


On 7 February 2016 at 02:54, Bryce Harrington <bryce@...961...> wrote:
On Thu, Feb 04, 2016 at 08:42:38AM -0500, Martin Owens wrote:
> On Thu, 2016-02-04 at 10:23 +0100, Sebastian Zartner wrote:
> > While I am currently not involved in the Inkscape development at all,
> > I have some experience with release processes and may help to define a
> > proper development and release cycle.
>
> Dear Sebastian,
>
> There is a process for releases and the main component is a release
> sponsor or main coordinator. I believe the lack of sponsor is the main
> reason for not getting a 0.92 version released any sooner. Although I
> would love to see one on the sooner side.

No, the duty here is on me.  It's not a problem of lack of a belly
button for the task, but more of a time overcommitment issue.

For 0.92, the specific thing blocking the release from proceeding is
needing to get the cmake build system fully squared away.  To that end,
I recently posted a list of remaining tasks where I need help:

  http://wiki.inkscape.org/wiki/index.php/CMake_Tasks

Some of those may already be done, but need to be doublechecked.  Once
all the 0.92 priorities are crossed off, then I think we can go ahead
and proceed with the release.

Besides cmake, the one other thing that must be done is a review of the
current release stability.  But so long as we don't have any development
work in intermediate stages, and no absolutely killer bugs, I think we
could cut a release and plan on a point release.  We did a pretty
through scrub last time we were all focusing on getting 0.92 done, and
assuming things haven't majorly deteriorated since then, I think this
would be fine.

> Bryce, do you have links we can share with Sebastian showing the
> organisational side for 0.91? Maybe they can help make the process
> better for the next release?

Yeah I've been keeping the release coordination links on wiki pretty up
to date with the specifics of the process.  However, with the build
system and now potentially the vcs system likely to change soon, a lot
is in flux.

The #1 best thing that can be done right now to improve the release
process is to strengthen the build system.  A lot of manual tasks in the
release will go away or be more easily automated once we can get unified
onto cmake (indeed this is my primary motivation for hammering on the
cmake transition).

Automating the procedure of actually uploading the distribution package
to the website and making the associated web collateral get updated
would be a big improvement too, but honestly that work is pretty small
scope in the grand scheme of things.  But boiling the release process
down to a single script or small number of scripts that can be run, is a
long term goal.  With our current release cadence the benefit will be
minimal, but if we move to a faster cadence it could help a lot.  I seem
to recall once we decide to cut a release, it is on the order of a
couple evenings to get it out.

Frankly the actual mechanics of doing a release, while more cumbersome
than they should be, aren't where we usually get hung up and delayed.
What causes the delays are unfinished work and bugs, and needing to
verify that we are indeed stable enough to release.  And that's an area
I would definitely love to see some discussion around how we could
improve.

There is also some time consumed each release on translation work,
documenting, advocacy/promotion, and so forth, but a lot of that has
already been nicely distributed amongst the team and there are efforts
ongoing to improve them.  With our releases being so infrequent, the
promotion efforts seem to always have to start from scratch, and I
suspect we could do a lot better there, but likely if we improve the
release cadence technically, this bit will become more tractable.

Anyway, I would love if we could move to a model where we're doing a
full release once every few months, and Sebastian I'd love to take you
up on your offer of assistance to achieve this!

Bryce

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel