Every download link for the development builds ..being a windows build or a deb should be on the main Inkscape website.

I can offer some GB's as a mirror for the binary builds ( 2 servers - approx. 10 Gb each for start ).

2014-03-26 18:43 GMT+02:00 Martin Owens <doctormo@...400...>:

On Wed, 2014-03-26 at 17:32 +0100, su_v wrote:

...

There is a PPA for trunk (daily) for Ubuntu users, and the most recent development snapshot build for Windows available for download is r13146, uploaded on March 14, 2014.

These steps are good, but certainly not ideal. I'm thinking about ways to put the download link on the inkscape.org website and perhaps if we can ask the builder of the packages to upload or link to a fixed name like "inkscape_trunk_latest.foo" etc

I'm also not keen on 7z files for distribution. exe or msi files for windows. Although perhaps the 7z is something to do with the one drive.

The alternative is that we carve out a small space on the inkscape website itself for posting the latest builds for the platforms and keep them there. Just one version (we only have 8GB on the server) make a little web form to put them up.

thoughts?

Martin,

---

Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

When I follow links as you describe - the latest build I can see is Oct 2013

On 3/27/2014 5:32 AM, su_v wrote:

On 2014-03-26 10:12 +0100, Sebastian Zartner wrote:

...

Unfortunately the provided development downloads are not synchronized, hosted on different third-party web sites and out of date (currently especially the Windows version).

There is a PPA for trunk (daily) for Ubuntu users, and the most recent development snapshot build for Windows available for download is r13146, uploaded on March 14, 2014.

The download link for Windows development builds unfortunately seems to confuse a lot of users:

1. Broswe here:

http://inkscape.org/en/download/windows/

2. Click on the link 'OSS-Marketplace.com'

http://www.oss-marketplace.com/index.php/downloads-mainmenu-63/Inkscape/Entwicklerversionen/

3. On this page, scroll down to

'aktuelleste Version / latest build' and click on the 'Download' link.

4. You'll now get forwarded to the onedrive page where the most recent builds are hosted:

https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A!217

5. Change the layout to list ('Details view' icon top left), and download the bottom-most 7z package:

currently: inkscape_r13149-201403142012.7z

The file 'inkscape_r13149-201403142012-dbg.7z' contains the debug symbols only.

hth, V

---

Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Any chance you could add build date and revision number, e.g. to the file names of the available archives?

Regards, V

On 2014-04-01 17:14 +0100, the Adib wrote:

As I don't know how we might continue with the publication of daily builds I put the todays versions on my Google Drive. Here is the link: https://drive.google.com/folderview?id=0ByQpCQ-C8wR2b09fYkRTSVk5bWM&usp=... There is:

• bat a bat file that gets the source, compiles and creates the installer
• 7z archived complete directory
• msi new wix based installer

the optimum would be a "cron job" that builds and publishes the archives etc.

Adib.

On Thu, Mar 27, 2014 at 11:30 AM, Mark Schafer <mschafer@...2596... mailto:mschafer@...2596...> wrote:

When I follow links as you describe - the latest build I can see is
Oct 2013

On 3/27/2014 5:32 AM, su_v wrote:
> On 2014-03-26 10:12 +0100, Sebastian Zartner wrote:
>
>> Unfortunately the provided development downloads are not
synchronized,
>> hosted on different third-party web sites and out of date (currently
>> especially the Windows version).
> There is a PPA for trunk (daily) for Ubuntu users, and the most recent
> development snapshot build for Windows available for download is
r13146,
> uploaded on March 14, 2014.
>
> The download link for Windows development builds unfortunately
seems to
> confuse a lot of users:
>
> 1) Broswe here:
> <http://inkscape.org/en/download/windows/>
>
> 2) Click on the link 'OSS-Marketplace.com'
>
<http://www.oss-marketplace.com/index.php/downloads-mainmenu-63/Inkscape/Entwicklerversionen/>
>
> 3) On this page, scroll down to
> 'aktuelleste Version / latest build' and click on the 'Download' link.
>
> 4) You'll now get forwarded to the onedrive page where the most
recent builds are hosted:
>
<https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A!217
<https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A%21217>>
>
> 5) Change the layout to list ('Details view' icon top left), and
download the bottom-most 7z package:
> currently: inkscape_r13149-201403142012.7z
>
> The file 'inkscape_r13149-201403142012-dbg.7z' contains the debug
symbols only.
>
>
> hth, V
>
>
------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

It sounds like there is already some progress in this direction. Though I want to point out again, that my request was not only for having regular alpha builds but also to shorten and regularize the release cycle for stable releases. I imagine that there could be a release every 3 or 4 months instead of having many months or even years between them. Users expect to get regular updates and they don't want to wait endlessly for the next version.

Sebastian

On 1 April 2014 19:15, the Adib <theadib@...400...> wrote:

I changed the filenames and will update the batch files accordingly.

Regards,

Adib.

On Tue, Apr 1, 2014 at 4:26 PM, su_v <suv-sf@...58...> wrote:

...

Any chance you could add build date and revision number, e.g. to the file names of the available archives?

Regards, V

On 2014-04-01 17:14 +0100, the Adib wrote:

...

As I don't know how we might continue with the publication of daily builds I put the todays versions on my Google Drive. Here is the link:

https://drive.google.com/folderview?id=0ByQpCQ-C8wR2b09fYkRTSVk5bWM&usp=...

...

There is:

• bat a bat file that gets the source, compiles and creates the

installer

...

• 7z archived complete directory
• msi new wix based installer

the optimum would be a "cron job" that builds and publishes the archives etc.

Adib.

On Thu, Mar 27, 2014 at 11:30 AM, Mark Schafer <mschafer@...2596... mailto:mschafer@...2596...> wrote:

When I follow links as you describe - the latest build I can see is
Oct 2013

On 3/27/2014 5:32 AM, su_v wrote:
> On 2014-03-26 10:12 +0100, Sebastian Zartner wrote:
>
>> Unfortunately the provided development downloads are not
synchronized,
>> hosted on different third-party web sites and out of date

(currently

...

>> especially the Windows version).
> There is a PPA for trunk (daily) for Ubuntu users, and the most

recent

...

> development snapshot build for Windows available for download is
r13146,
> uploaded on March 14, 2014.
>
> The download link for Windows development builds unfortunately
seems to
> confuse a lot of users:
>
> 1) Broswe here:
> <http://inkscape.org/en/download/windows/>
>
> 2) Click on the link 'OSS-Marketplace.com'
>
<

http://www.oss-marketplace.com/index.php/downloads-mainmenu-63/Inkscape/Entw...

...

>
> 3) On this page, scroll down to
> 'aktuelleste Version / latest build' and click on the 'Download'

link.

...

>
> 4) You'll now get forwarded to the onedrive page where the most
recent builds are hosted:
>
<

https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A!217

...

<

https://onedrive.live.com/?cid=09706d11303fa52a&id=9706D11303FA52A%21217

...

...

>
> 5) Change the layout to list ('Details view' icon top left), and
download the bottom-most 7z package:
> currently: inkscape_r13149-201403142012.7z
>
> The file 'inkscape_r13149-201403142012-dbg.7z' contains the debug
symbols only.
>
>
> hth, V
>
>

---

...

> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book

today!

...

> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

---

...

_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

...

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 18 May 2014 14:37, Alexandre Prokoudine wrote:

On Sun, May 18, 2014 at 4:18 AM, Sebastian Zartner wrote:

...

It sounds like there is already some progress in this direction. Though I want to point out again, that my request was not only for having regular alpha builds but also to shorten and regularize the release cycle for stable releases.

In my humble opinion, people who request this sort of thing should

1. volunteer to become release managers;
2. deliver on that.

I actually already do that, but not for the Inkscape project but for the Firebug project https://getfirebug.com/, which already takes all my spare time. So I was in the hope somebody of the current Inkscape team would feel responsible for this task.

Sebastian

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.

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?

Best Regards, Martin Owens

(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. https://play.google.com/store/search?q=alfamem

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Mon, Feb 08, 2016 at 10:31:05AM +0100, Sebastian Zartner wrote:

Dear Martin, dear Bryce,

thank you very much for replying and giving some more details on this.

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.

Regarding unfinished work and bugs I agree with Olof that this needs some changes in the workflow. What I would do different in regard of Olof's proposal is to create a branch for every (bigger) feature instead of having one dev branch. Also, a release may not be done at a fixed date, you may also do it depending on the number of new features/changes. If you remember, I already mentioned that earlier[1] (and you already agreed to this[2]). This would also play nicely with the workflow on GitHub and its pull requests if your discussion about switching to git concludes to use it as platform.

I hear you. I am a strong proponent of use of branches, particularly for features, but really any work that isn't trivial. In theory, what you're describing should be a very good system.

Unfortunately in practice there are other aspects that make it not so easy.

Most notably, volunteer developers like to see their work used by others (both for technical reasons - i.e. testing, as well as for earning kudos from users). But if you are diligent and disciplined about keeping your work off on a branch, it's unlikely you'll be able to get either of these. Someone who is not branch-disciplined and instead pushes directly to trunk, gets both rapid feedback from testing and more instant recognition of their work.

So, essentially, the incentive structure kind of works against feature branches.

If we were a company we could simply mandate workflows, but in a volunteer project like ours, we risk alienating developers or at least reducing the incentives they get for keeping up their efforts.

Not to say that feature branches are a bad idea - like I said up front, I'm a strong advocate for that and use it myself. I think a lot of developers also do work on branches on their own initiative. But implementing it project-wide has some trickiness to it.

Last release I did experiment with having people work on their feature branches, and then land them into an 'experimental' branch parallel to the stable release tree, and then we merged that work in post-release. I don't think I could call it a resounding success; I think people mostly put up with it, or maybe even just took a development vacation. With there being a split between stable and experimental, a lot of people simply ran one or the other depending on their interest, thus splitting our testing efforts. Bugfixing activity was not noticeably better, and I don't think I could honestly say it improved our release velocity. It did increase the workload and complexity for our bug team. In terms of stability, I don't think I'd necessarily say the experimental branch ended up being that much more buggy than the stable branch; folks were pretty good about cleaning up problems as they cropped up.

It is possible that things could be different with git. Merging in git seems like it ends up working better than with bzr (maybe it's just me). git rebase and format-patch and other such tools are well suited for doing more highly distributed feature coding work.

Bryce

On 11 February 2016 at 19:35, Christoffer Holmstedt <christoffer.holmstedt@...400...> wrote:

2016-02-11 9:15 GMT+01:00 Bryce Harrington <bryce@...961...>:

...

On Mon, Feb 08, 2016 at 10:31:05AM +0100, Sebastian Zartner wrote:

...

Dear Martin, dear Bryce,

thank you very much for replying and giving some more details on this.

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.

Regarding unfinished work and bugs I agree with Olof that this needs some changes in the workflow. What I would do different in regard of Olof's proposal is to create a branch for every (bigger) feature instead of having one dev branch. Also, a release may not be done at a fixed date, you may also do it depending on the number of new features/changes. If you remember, I already mentioned that earlier[1] (and you already agreed to this[2]). This would also play nicely with the workflow on GitHub and its pull requests if your discussion about switching to git concludes to use it as platform.

I hear you. I am a strong proponent of use of branches, particularly for features, but really any work that isn't trivial. In theory, what you're describing should be a very good system.

Unfortunately in practice there are other aspects that make it not so easy.

Most notably, volunteer developers like to see their work used by others (both for technical reasons - i.e. testing, as well as for earning kudos from users). But if you are diligent and disciplined about keeping your work off on a branch, it's unlikely you'll be able to get either of these. Someone who is not branch-disciplined and instead pushes directly to trunk, gets both rapid feedback from testing and more instant recognition of their work.

So, essentially, the incentive structure kind of works against feature branches.

If we were a company we could simply mandate workflows, but in a volunteer project like ours, we risk alienating developers or at least reducing the incentives they get for keeping up their efforts.

Not to say that feature branches are a bad idea - like I said up front, I'm a strong advocate for that and use it myself. I think a lot of developers also do work on branches on their own initiative. But implementing it project-wide has some trickiness to it.

Last release I did experiment with having people work on their feature branches, and then land them into an 'experimental' branch parallel to the stable release tree, and then we merged that work in post-release. I don't think I could call it a resounding success; I think people mostly put up with it, or maybe even just took a development vacation. With there being a split between stable and experimental, a lot of people simply ran one or the other depending on their interest, thus splitting our testing efforts. Bugfixing activity was not noticeably better, and I don't think I could honestly say it improved our release velocity. It did increase the workload and complexity for our bug team. In terms of stability, I don't think I'd necessarily say the experimental branch ended up being that much more buggy than the stable branch; folks were pretty good about cleaning up problems as they cropped up.

It is possible that things could be different with git. Merging in git seems like it ends up working better than with bzr (maybe it's just me). git rebase and format-patch and other such tools are well suited for doing more highly distributed feature coding work.

Bryce

This is an interesting discussion in times of Continuous Integration, Continuous Delivery, DevOps and all other fancy names for it. For me it all boils down to a few things; merge to trunk/master often (at least once every hour) and always keep it buildable and runnable without critical crashes for the end user. My feeling is that more and more companies/projects move away from time-slotted releases and try to release several times every day. Just last week the following showed up on hackernews [1] as an example. Instead of an Inkscape release every 6 months I would rather see daily/weekly releases, mostly automated from Travis CI, Jenkins or similar system. Of course, a bump in the major version number would require manual intervention for such a release, but that shouldn't require more than a push of a button.

[1] http://engineering.skybettingandgaming.com/2016/02/02/how-we-release-so-freq...

A really interesting article, Christoffer!

I am on your side for a highly automated release process. Though I've not heard so far of any desktop software doing daily stable releases. Also for Inkscape I wouldn't go for a daily or weekly release of main versions, as I assume the network infrastructure wouldn't allow a huge amount of daily downloads. Having said that - as I mentioned earlier - I do agree that there should be nightly releases for testing purposes and regular alpha and beta releases accompanied by some release notes for people wanting to try out the latest features.

Sebastian

On 11 February 2016 at 20:52, Martin Owens <doctormo@...400...> wrote:

On Thu, 2016-02-11 at 20:38 +0100, Sebastian Zartner wrote:

...

as I assume the network infrastructure wouldn't allow a huge amount of daily downloads.

As mentioned before, the network infrastructure is serving 40TB a month from our live website. (That's the equivalent of 950,000 downloads of the windows installer per month) which is A LOT. (please don't use this as a statistic, the logs tell a more direct picture that's not that high.)

That are really impressive numbers! Anyway, doing nightly releases for a smaller audience sounds great. (And I love to try out the latest versions of programs.) Though I still believe doing daily or even weekly releases to the *full* audience of people is not necessary, especially not without a development infrastructure like the one described in the blog linked to by Christoffer.

Side note: Together with daily releases an easy update process should be set up. I.e. an option inside the program allowing you to check for and install updates automatically.

Sebastian

El jue, 11-02-2016 a las 14:52 -0500, Martin Owens escribió:

On Thu, 2016-02-11 at 20:38 +0100, Sebastian Zartner wrote:

...

as I assume the network infrastructure wouldn't allow a huge amount of daily downloads.

As mentioned before, the network infrastructure is serving 40TB a month from our live website. (That's the equivalent of 950,000 downloads of the windows installer per month) which is A LOT. (please don't use this as a statistic, the logs tell a more direct picture that's not that high.)

I insist that a charging for binaries could be an excellent way to get funds to get funding for the less sexy tasks (the ones that take away fun from working in free-software projects). What about a "pay what you want" model starting by 1 usd? Not comfortable with that? What about a pay what you want, and a part of that money goes to a charity, as Humble Indie Bundle does?

This is not necessarily incompatible with the GPL, as you can still offer the sources freely to let people and linux distributions build their own packages. It's just charging a tiny wee bit to the users for the convenience of packaging the software for them (which is also a task that is not exactly fun for people to do).

Some of the money could go to Partha or whoever wants to put the builder hat, and the rest could go to fund hopefully full time developers for the non-fun parts of the project.

Gez.

On Mon, Feb 15, 2016 at 2:47 PM, Krzysztof Kosiński wrote:

A problem with this is that a paywall on the official site will drive people to unofficial download locations, and these may contain trojans or other malware.

I have yet to see this happen for Ardour.

Alex

I think suggest a donation is a good idea.

New releases in inkscape-web can handle this when start using it.  Maybe is time to fill a bug in inkscape-web if is the desired option.

Also we can move to a help page to donate and also show cool inkscape merchandaising.

El lun, 15-02-2016 a las 13:30 +0100, Olof Bjarnason escribió:

I think Launchy's model is nice. Suggest a (modifiable/optional) donation on download page, but don't force anything. On 15 Feb 2016 12:48, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:

...

2016-02-14 12:21 GMT-08:00 Gez <listas@...3059...>:

...

El jue, 11-02-2016 a las 14:52 -0500, Martin Owens escribió:

...

On Thu, 2016-02-11 at 20:38 +0100, Sebastian Zartner wrote:

...

as I assume the network infrastructure wouldn't allow a huge amount of daily downloads.

As mentioned before, the network infrastructure is serving 40TB a month from our live website. (That's the equivalent of 950,000 downloads of the windows installer per month) which is A LOT. (please don't use this as a statistic, the logs tell a more direct picture that's not that high.)

I insist that a charging for binaries could be an excellent way to get funds to get funding for the less sexy tasks (the ones that take away fun from working in free-software projects). What about a "pay what you want" model starting by 1 usd? Not comfortable with that? What about a pay what you want, and a part of that money goes to a charity, as Humble Indie Bundle does?

A problem with this is that a paywall on the official site will drive people to unofficial download locations, and these may contain trojans or other malware. (See the SourceForge fiasco, though apparently they stopped doing that.)

Some kind of button or interstitial that would encourage people to donate when downloading Inkscape would be okay, but a full-on paywall doesn't seem like a good idea to me.

Best regards, Krzysztof

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Am Donnerstag, 11. Februar 2016, 19:35:38 schrieb Christoffer Holmstedt:

[giant quote]

Of course, a bump in the major version number would require manual intervention for such a release, but that shouldn't require more than a push of a button.

I don't think that that would work with real programs. You'd still need at least string freezes for translators.

Basically, the primary reason to write free software should be the fun the programmers have. If it takes a little longer to release doesn't really matter. Sure, it shouldn't take forever, after all you want some feedback before forgetting that fancy new feature you wrote. But complicating matters so much that it's just another day job and no longer the fun hobby is surely a bad idea and going to drive away contributors.

Tobias

On Thu, 2016-02-11 at 23:21 +0100, Tobias Ellinghaus wrote:

Basically, the primary reason to write free software should be the fun the programmers have.

I'm issuing my highest disagree. Not that many programmers don't have fun, or that many developers currently think that Free Software is only a bit of fun; but that we have users, they have needs, we're ghastly at serving those needs.

Not to say we promised them anything of course, but the potential to make software that is designed for users instead of developers is there if we want it, that is, if we want to talk to users, take their money and serve users with Free Software. Which of course we're not doing [yet] and which does effect the sustainability and the design direction of all Free Software projects.

Sometimes I really think the FSF let us all down by focusing so hard of politics, they forgot about users, economics and the fantastic kindness already woven in many of our projects.

so much that it's just another day job and no longer the fun hobby is surely a bad idea and going to drive away contributors.

Many contributors will contribute for lots of reasons. Certainly the long tail should be respected and having lots of small casual contributions is a healthy sign of a welcoming project. But don't forget that there is room for a professional class too [not better social class, think economic interface mixin] who's job, and fun, can come from thinking hard about what other people want, people who aren't programmers and who don't have the power to contribute through code.

Thinking of others is hard, it's hard to listen, it's hard to discuss and process ideas over multiple levels of sophistication. I don't mind that it's something most people would rather not do, but it'd be a sign of a great project when there are people who looked after users. I don't want people to have hard jobs they don't want to do, but I don't want us to get into the mindset that only one type of developer with one type of agenda is possible in the Free Software ecosystem.

Kind Regards, Martin Owens

Am Freitag, 12. Februar 2016, 04:57:12 schrieb Martin Owens:

[...]

Thinking of others is hard, it's hard to listen, it's hard to discuss and process ideas over multiple levels of sophistication. I don't mind that it's something most people would rather not do, but it'd be a sign of a great project when there are people who looked after users. I don't want people to have hard jobs they don't want to do, but I don't want us to get into the mindset that only one type of developer with one type of agenda is possible in the Free Software ecosystem.

And why would you do that, listen to users and think about how to tailor the program to suit them? Exactly: because it's fun to do that.

I never said (or wanted to imply) that developers shouldn't care about users. But as the only benefit they get is the fun for doing it (*) projects would be wise to not implement anything that takes the only reason to contribute away from contributors. And sometimes implementing strict rules about how things have to be done (for many everything besides writing code, like tests, management stuff, ...) might hurt more than one might expect when thinking about the same rules in a professional setting where people just have to accept them for their motivator being money. It's easier to walk away when fun is the thing you are looking for than when you have to do it to pay your bills.

Kind Regards, Martin Owens

Tobias

(*) I am talking about voluntary developers. I don't care about paid people here, they might be chained to a desk and threatened with a whip so I won't speculate on their motivation and if they should be catered for when coming up with policies.

On Sat, 2016-02-13 at 18:03 +0100, Tobias Ellinghaus wrote:

And why would you do that, listen to users and think about how to tailor the program to suit them? Exactly: because it's fun to do that.

For some people, yes. For many, it's not. Getting data about users that isn't anecdotal is more complex and uses processes that many developers aren't entirely aware of.

(*) I am talking about voluntary developers. I don't care about paid people here, they might be chained to a desk and threatened with a whip so I won't speculate on their motivation and if they should be catered for when coming up with policies.

Programmers are in such high demand right now that money is simply not a motivator to anyone. Even a paid developer will have to be having fun, but the difference is that the developer will be able to execute more of their time in the project. Hence sustainability, not motivation.

As for rules; making sure that contributors can easily contribute is a major goal in this project. Few other projects think so much about how to make the project available to the widest possible number as Inkscape does.

So is the /primary/ reason fun for all developers? No. Is it something all developers are looking out for? Yes. We have no argument here in principle; but the project shouldn't be subdued from making statements about professional conduct because the first goal is now having a laugh. We can be professionals and volunteers having fun and getting stuff done.

Best Regards, Martin Owens

(*) You say you don't care about people, but I think you were being hyperbolic here.

Dear Gez,

On Sun, 2016-02-14 at 03:01 -0300, Gez wrote:

Now, I'm well aware that it's difficult to produce high quality software when the resources are limited so I'm not expecting magic here. I know that using free software from a project run by volunteers will require making some sacrifices and lowering the expectations a bit, and as a users who runs his design firm with free software exclusively I know I have.

Conversely users have a responsibility to invest in the project too. Part of what I'm trying to communicate is that there must be space for developers to not be charity volunteers and space for users to be more than freeloaders. There is plenty of responsibility for everyone :-D

Martin,

On 11 February 2016 at 09:15, Bryce Harrington <bryce@...961...> wrote:

On Mon, Feb 08, 2016 at 10:31:05AM +0100, Sebastian Zartner wrote:

...

Dear Martin, dear Bryce,

thank you very much for replying and giving some more details on this.

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.

Regarding unfinished work and bugs I agree with Olof that this needs some changes in the workflow. What I would do different in regard of Olof's proposal is to create a branch for every (bigger) feature instead of having one dev branch. Also, a release may not be done at a fixed date, you may also do it depending on the number of new features/changes. If you remember, I already mentioned that earlier[1] (and you already agreed to this[2]). This would also play nicely with the workflow on GitHub and its pull requests if your discussion about switching to git concludes to use it as platform.

I hear you. I am a strong proponent of use of branches, particularly for features, but really any work that isn't trivial. In theory, what you're describing should be a very good system.

Unfortunately in practice there are other aspects that make it not so easy.

Most notably, volunteer developers like to see their work used by others (both for technical reasons - i.e. testing, as well as for earning kudos from users). But if you are diligent and disciplined about keeping your work off on a branch, it's unlikely you'll be able to get either of these. Someone who is not branch-disciplined and instead pushes directly to trunk, gets both rapid feedback from testing and more instant recognition of their work.

So, essentially, the incentive structure kind of works against feature branches.

If we were a company we could simply mandate workflows, but in a volunteer project like ours, we risk alienating developers or at least reducing the incentives they get for keeping up their efforts.

Not to say that feature branches are a bad idea - like I said up front, I'm a strong advocate for that and use it myself. I think a lot of developers also do work on branches on their own initiative. But implementing it project-wide has some trickiness to it.

Last release I did experiment with having people work on their feature branches, and then land them into an 'experimental' branch parallel to the stable release tree, and then we merged that work in post-release. I don't think I could call it a resounding success; I think people mostly put up with it, or maybe even just took a development vacation. With there being a split between stable and experimental, a lot of people simply ran one or the other depending on their interest, thus splitting our testing efforts. Bugfixing activity was not noticeably better, and I don't think I could honestly say it improved our release velocity. It did increase the workload and complexity for our bug team. In terms of stability, I don't think I'd necessarily say the experimental branch ended up being that much more buggy than the stable branch; folks were pretty good about cleaning up problems as they cropped up.

It is possible that things could be different with git. Merging in git seems like it ends up working better than with bzr (maybe it's just me). git rebase and format-patch and other such tools are well suited for doing more highly distributed feature coding work.

Again, thank you for the insights, Bryce!

Let me also give you some insight into the workflow of the Firebug Working Group as an example, for which I was a long-term volunteer contributor and which is driven by a handful of volunteers besides one fulltime (paid) maintainer. Its development initially happened using Subversion on Google Code, where there was basically only a master branch and everybody pushed their code directly there. It had a unit testing suite, which needed to be triggered manually, though. When Google announced that Google Code will be shut down the team had to decide where to move. And as Google Code already provided an exporter to GitHub and due to good experiences from some of the team members, the decision was quickly made for it.

With the move to GitHub we also set up a new workflow[1] by moving from the single-branch system to using branches. The core contributors were still able to push their code directly to master, though the guideline was to use branches for bigger changes and to never break the master branch. So, everybody started creating branches for new features and bigger changes, ran the unit tests on their changes and once they were all green, merged the branch to master. And Git(Hub)'s tooling makes it very easy to work with branches and follow this workflow. The maintainer made a release about every week (!) and outlined in a blog post[2] the changes and newly added features.

Having this in mind, coming back to the points you mentioned:

volunteer developers like to see their work used by others for technical reasons - i.e. testing

Reviewing changes is an important part of the workflow, especially the first contributions.

as well as for earning kudos from users

Correct. That's one reason why you should do releases regularily and promote their changes.

But if you are diligent and disciplined about keeping your work off on a branch, it's unlikely you'll be able to get either of these.

I'd say having an overburdened workflow is the reason for that. E.g. having an extra experimental branch besides the master branch sounds like it makes things unnecessary complicated and likely repels (volunteer) contributors. I.e. only use one level of branching and - if human resources are insuficient for reviewing every change - allow (core) contributors to merge their changes to master.

Someone who is not branch-disciplined and instead pushes directly to trunk, gets both rapid feedback from testing and more instant recognition of their work.

Yes, but direct pushing is also more likely to break trunk. But you're right, that will also provide instant recognition. ;-) Though a slim process of merging branches also allows to get quick recognition.

So, the main point is to create an easy and transparent workflow, which allows to keep trunk/master stable and provides some control over what gets deployed.

Sebastian

[1] https://getfirebug.com/wiki/index.php/GIT_Development_Workflow [2] https://blog.getfirebug.com/page/3/