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

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

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/E... 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!21... 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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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&u... 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/E... > > 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%21... > > 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(a)lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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&u... > > 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/E... > > > > > > > > 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(a)lists.sourceforge.net > > <mailto:Inkscape-devel@lists.sourceforge.net> > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > <mailto:Inkscape-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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.

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.

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

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.

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-f...

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.)

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.)

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

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.

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

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.

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

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 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.

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.

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.

volunteer developers like to see their work used by others 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.