On Wed, Oct 20, 2010 at 10:21 PM, Juiceman <juiceman69 at gmail.com> wrote:
> > > On Wed, Oct 20, 2010 at 3:52 PM, Matthew Toseland < > toad at amphibian.dyndns.org> wrote: > >> On Monday 18 October 2010 14:30:48 Christian Funder Sommerlund wrote: >> > [From the minutes] >> > toad_ and nextgens bring up problems with the current windows installer, >> > and give a brief of its history. >> > >> > nextgens notes that the hardest part is to continuously maintain it, to >> > ensure that it keeps working. >> > >> > toad_ points out that he needs to purchase copies of Windows for testing >> > purposes. >> > >> > Various people discuss ways of implementing a windows installer, >> > including MSI/NSIS and even using a VM. >> > >> > infinity0 notes that this doesn't solve the problem of needing a regular >> > maintainer. >> > >> > p0s argues that the windows installer is an important component and >> > therefore by default falls to toad_ if no other suitable person can be >> > found. >> > >> > toad_ accepts this solution in the case where our current maintainer >> > Zero3 doesn't show up in time for the next release. >> > >> > sanity offers to provide windows licenses. >> > >> > [My comments] >> > I feel like I ought to comment on the above, being the one that made >> > (and kind-of maintains) the thing :). >> > >> > I'm not sure if it was mentioned at the meeting, but I'd like to point >> > out that the main issues throughout the years have been directly related >> > to >> > >> > A) The custom user we used (was removed some time ago) >> > B) The custom service we used (was removed in the latest alpha) >> > >> > (both of which I argued on getting rid of back when I originally built >> > our new windows installer, several years ago, but was overruled :() >> > >> > As we now know, neither of the above is easy to do properly across the >> > vast lanscape of Windows installations. A) isn't exactly good practice >> > on Windows anyway, but B) ought to be doable. B) will work on pretty >> > much any Windows machine out-of-the-box, but has showed to be impossibly >> > hard to make work reliably on certain existing setups. >> > >> > I agree with nextgens that one of the main issues is maintenance. The >> > first year or so after my initial version was easy enough for me to do >> > alone, given my situation back then, but since I've started on my CS >> > studies it has been increasingly difficult for me to find time for >> > maintaining it. Another person or two would help a lot. >> > >> > Regarding choice of installer (custom AHK vs. NSIS vs. MSI vs...), I >> > still believe that a custom installer is a huge bonus to usability. The >> > downside, however, is that it requires more maintenance compared to a >> > standardized wizard installer. >> >> Can you coordinate with Juiceman to get an update script sorted out for >> the alpha? (If necessary in cmd script). Are there any other critical issues >> that must be solved before deploying the alpha? >> > > Ok, I have installed the alpha on a VM. It looks like the start.exe and > stop.exe are no longer used? Also, the utilities wget.exe and sha1test.jar > aren't installed. > > I need to know the command line arguments to start and stop the node and > also if there are exit conditions (errorlevel 0, etc). > We need to make sure wget.exe, sha1test.jar and startssl.pem are > installed. Also it needs to be decided where those files will be > installed. I'm not clear what we're doing with the folder restructuring... > > I had committed update.exe which was just a wrapper to call update.cmd; > this was to prompt a UAC elevation (hopefully). Do we want to use this or > is it obsolete now? > > I can redo the update.cmd script if that is still the plan as long as the > above items are taken care of. > > Bump. Any response? -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101104/8492d0e2/attachment.html>
