Background Image and Drag to Install (was Re: [Inkscape-devel] new packaging for OS X)
On 24/04/06, jiho <jo.irisson@...400...> wrote:
On 24 Apr 2006, at 13:59 , Ben Fowler wrote:
On 24/04/06, jiho <jo.irisson@...400...> wrote:
Hi all,
[ snip ]
Could I underline that this is more than eye-candy: It is best practice to have a background image, showing that the way to install the application is to drag it to the folder of your choice. It is also advisable to somehow indicate where the application now is, to wit that the user will have to open the Applications folder (perhaps with Cmd-Shift-A) to see where they put it. ...
so you advise not to use the symlink to Apllications but rather to make the user open Applications (or anything else) and put inkscape there?
Well, I didn't mean to go into quite such a detail, but if you did want an opinion from me, I would be a little against it. (Does anybody else do this?).
Some people (most people) want to put apps in the System wide Applications folder, some people put apps in their ~/Applications folder - necessary if you do not have write permission to the System wide Applications folder, and some people plonk new apps onto their Desktop to try out, and then transfer to the proper place when they have checked them out.
I wouldn't expect a naive user to understand dropping an icon from part of a disk image to another.
The problem is making the instructions brief and multi-lingual. My guide is this page which has aged very well: http://www.g2meyer.com/usablehelp/dmggfx.html ,
I'll be unavailable for the next two months so I won't be able to produce Inkscape dev builds for the testing phase of the release, nor will I be able to package 0.44. I guess people will be available to do it. If this new packaging is ok to everybody and worth bothering, I'll modify the wiki to explain how to do it and somebody (Michael? Ted?) could take over the builds.
I think that they key to this is that there should be one person nominated to produced 'blessed' builds. FWIW, I have had to make a few modifications to the methods on the wiki, and I doubt that many people are producing Mac builds. This does not matter provided that one person can produce official builds - interested parties can download and test those.
I agree with you. I'll be happy to be the one to produce the "blessed" builds ;-) I just cannot do this for a while and I just need someone with a 10.4 machine to take over for two months (BTW, I mixed up the names and wrote Ted instead of Ben earlier. Even if you work on 10.3, do you have a 10.4 machine somewhere?).
Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload, I will do this, but it is possible that there are people here who could do a better job, and I won't be offended to be relieved of this duty, if necessary!
Ben
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
I'll be unavailable for the next two months so I won't be able to produce Inkscape dev builds for the testing phase of the release, nor will I be able to package 0.44. I guess people will be available to do it. If this new packaging is ok to everybody and worth bothering, I'll modify the wiki to explain how to do it and somebody (Michael? Ted?) could take over the builds.
I think that they key to this is that there should be one person nominated to produced 'blessed' builds. FWIW, I have had to make a few modifications to the methods on the wiki, and I doubt that many people are producing Mac builds. This does not matter provided that one person can produce official builds - interested parties can download and test those.
I agree with you. I'll be happy to be the one to produce the "blessed" builds ;-) I just cannot do this for a while and I just need someone with a 10.4 machine to take over for two months (BTW, I mixed up the names and wrote Ted instead of Ben earlier. Even if you work on 10.3, do you have a 10.4 machine somewhere?).
Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload, I will do this, but it is possible that there are people here who could do a better job, and I won't be offended to be relieved of this duty, if necessary!
Having official OSX packagers would be a big help for the OSX users, and I think the other developers would love having a point of contact for it.
Regarding the upload processes, be aware there are two separate processes - one for "official" builds such as pre-release candidates and the releases themselves, and another process for doing automated daily builds.
I (or one of the other Inkscape admins) can set up your sourceforge account, which you'll need to be able to post packages for the first process.
For the second type of release, we have a server where you can have the scripts upload the daily builds to. Check with ACSpike to see what the current procedure is.
Bryce
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
[ snip ]
Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload,
[ snip ]
Regarding the upload processes, be aware there are two separate processes - one for "official" builds such as pre-release candidates and the releases themselves, and another process for doing automated daily builds.
I (or one of the other Inkscape admins) can set up your sourceforge account, which you'll need to be able to post packages for the first process.
It would be wise to do this, but I don't want to tread on Michael's toes.
For the second type of release, we have a server where you can have the scripts upload the daily builds to. Check with ACSpike to see what the current procedure is.
Again, we should be doing this (not sure if you mean giving a script to the server and having it run regularly to make the builds, or having a place to upload builds done off-line).
Ben
On 25 Apr 2006, at 09:48 , Ben Fowler wrote:
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
[ snip ]
Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload,
[ snip ]
Regarding the upload processes, be aware there are two separate processes - one for "official" builds such as pre-release candidates and the releases themselves, and another process for doing automated daily builds.
I (or one of the other Inkscape admins) can set up your sourceforge account, which you'll need to be able to post packages for the first process.
It would be wise to do this, but I don't want to tread on Michael's toes.
For the second type of release, we have a server where you can have the scripts upload the daily builds to. Check with ACSpike to see what the current procedure is.
Again, we should be doing this (not sure if you mean giving a script to the server and having it run regularly to make the builds, or having a place to upload builds done off-line).
the server is just a hosting place so I build the nightlies on my computer (not as regularly as I would like to I am afraid) and I uploaded them to the server afterwards. All the building/packaging indications are on the wiki http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX with a bash script to automatize the process. What do you mean by smoke testing? To upload, aaron spike is in charge.
cheers,
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 25/04/06, jiho <jo.irisson@...400...> wrote:
On 25 Apr 2006, at 09:48 , Ben Fowler wrote:
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
[ big snip] Again, we should be doing this ...
the server is just a hosting place so I build the nightlies on my computer (not as regularly as I would like to I am afraid) and I uploaded them to the server afterwards.
We could just make a rule that if one of us saw that the deliverable offered for download was more than a few days old, and there was a 'good' build available then it should be uploaded, with a note as to who built it.
BTW the Bug Report "[ 1447658 ] [WEB SITE] Mac OSX development binaries won't download" seems to be WORKSFORME, in that the im ages can be downloaded.
What do you mean by smoke testing?
Two things, either
1) An series of quick tests that a dev can do to be sure that the build is good. or 2) An assertion that the tests concerned have been done.
For a long time, my smoke test was to create a new document, make a star and a rectangle and perfom a path union on those two objects. If this worked I was happy. If it didn't I knew that something was definitely wrong. Obviously each dev will have their own choice of tests, and it is best that the test actually done is in an area where development is taking place, but it is more important that the smoke test is quick and simple so that there is no temptation to neglect it.
Ben.
On 25 Apr 2006, at 18:51 , Ben Fowler wrote:
On 25/04/06, jiho <jo.irisson@...400...> wrote:
On 25 Apr 2006, at 09:48 , Ben Fowler wrote:
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
[ big snip] Again, we should be doing this ...
the server is just a hosting place so I build the nightlies on my computer (not as regularly as I would like to I am afraid) and I uploaded them to the server afterwards.
We could just make a rule that if one of us saw that the deliverable offered for download was more than a few days old, and there was a 'good' build available then it should be uploaded, with a note as to who built it.
ok, why not. I'll try to keep them as recent as I can in order to take the load of your backs... but only when I'll be back of course. For the note I propose uploading a file named Inkscape_somedate_info.txt with the build Inkscape_somedate.dmg with fields:
OS X version: Fink version: Fink distribution: gcc version: configure options: stripped: YES/NO
BTW the Bug Report "[ 1447658 ] [WEB SITE] Mac OSX development binaries won't download" seems to be WORKSFORME, in that the im ages can be downloaded.
Yes this was relevant to builds hosted on the main website. can somebody with administrative rights close this one?
What do you mean by smoke testing?
Two things, either
- An series of quick tests that a dev can do to be sure that the
build is good. or 2) An assertion that the tests concerned have been done.
For a long time, my smoke test was to create a new document, make a star and a rectangle and perfom a path union on those two objects. If this worked I was happy. If it didn't I knew that something was definitely wrong. Obviously each dev will have their own choice of tests, and it is best that the test actually done is in an area where development is taking place, but it is more important that the smoke test is quick and simple so that there is no temptation to neglect it.
OK. I do test the builds in a similar way. what could be nice also is a small script which check if all locale information, tutorials and so on are present in the app bundle (there used to be problems with this).
I uploaded a last dev build today, build with OS X 10.4, gcc 4 and latest fink. I also updated substantially the wiki. Let me know by personal email if everything is fine (I turn off list delivery for the time I am away)
See you,
Jean-Olivier Irisson --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- Personal address: Château St Martin, 66200 Elne, France Professional address: EPHE- UMR CNRS 8046, 52 av Paul Alduy, 66860 Perpignan Cedex, France
Mobile: 06 21 05 19 90 Web site: http://jo.irisson.free.fr/work/
tests, and it is best that the test actually done is in an area where development is taking place, but it is more important that the smoke test is quick and simple so that there is no temptation to neglect it.
OK. I do test the builds in a similar way. what could be nice also is a small script which check if all locale information, tutorials and so on are present in the app bundle (there used to be problems with this).
Dont know much about make but this sounds like it might becovered by:
make distcheck http://sources.redhat.com/autobook/autobook/autobook_102.html
On Tue, Apr 25, 2006 at 05:51:48PM +0100, Ben Fowler wrote:
What do you mean by smoke testing?
Two things, either
- An series of quick tests that a dev can do to be sure that the
build is good. or 2) An assertion that the tests concerned have been done.
By the way, for the former, there is now a `make check` capability that Jon Cruz, Mental, and others have worked on, that runs a sequence of unit tests. The coverage is far from 100%, but it runs quick, and it would be very appropriate to run as part of the "smoke testing".
Bryce
On 28/04/06, Bryce Harrington <bryce@...961...> wrote:
On Tue, Apr 25, 2006 at 05:51:48PM +0100, Ben Fowler wrote:
What do you mean by smoke testing?
By the way, for the former, there is now a `make check` capability that Jon Cruz, Mental, and others have worked on, that runs a sequence of unit tests. The coverage is far from 100%, but it runs quick, and it would be very appropriate to run as part of the "smoke testing".
That's right.
I've certainly found 'make check' useful on one occasion in the past. IMHO "unit tests" sometimes means different things to different people: I have heard it said that unit tests should be written to cover every tranche of new code; unti tests should be run (at 100% success) at every compile; unit tests should be run before check-in. Whilst there is such as thing as too much process, modern thinking is that unit testing - test infected - is the human readable term, is the way to provide an uptodate design, in the form of a living document.
Ideally, before putting out a build for testers, we ought to go one step further, and be sure that the build is good enough to warrant the time of another person, which is what I had in mind.
IMHO, if we do have people who are doing testing and nothing else, their names should be at the front of the Credits document, as these are the people to thank for the quality of Inkscape.
Ben
On Apr 28, 2006, at 2:53 PM, Ben Fowler wrote:
I've certainly found 'make check' useful on one occasion in the past. IMHO "unit tests" sometimes means different things to different people: I have heard it said that unit tests should be written to cover every tranche of new code; unti tests should be run (at 100% success) at every compile; unit tests should be run before check-in. Whilst there is such as thing as too much process, modern thinking is that unit testing - test infected - is the human readable term, is the way to provide an uptodate design, in the form of a living document.
Actually... rather than "test infected" we really want to be getting focused on "test driven development"
However, to point out things, you've hit some mix of features and uses of unit tests.
For definition/aspects of ...
Basically, a "unit test" tests some unit of software, usually a module of some sort. It will run through API's and such to ensure that base functionality is as expected.
Then we have "integration test", where pieces are put together and system is checked for overall operation.
"Regression tests" are those that are done to make sure that things that were once fixed stay fixed, and don't "regress" to be broken again. Often unit tests can be run as part of regression testing.
For uses....
Once one has unit tests in, maximizing their benefit is good. Running all unit tests before checkin is a very good thing. Running them each and every developer build is even better.
Test Driven Develop goes on to say that you shouldn't bother writing anything that you don't code the unit tests for first. If you can't create a unit test for some function, then you either don't need that function, or don't understand what you're doing.
On 29/04/06, Jon A. Cruz <jon@...18...> wrote:
On Apr 28, 2006, at 2:53 PM, Ben Fowler wrote:
[ snip ]
Actually... rather than "test infected" we really want to be getting focused on "test driven development"
However, to point out things, you've hit some mix of features and uses of unit tests.
Suppose I say that I agree with you 100% and agree to drop the term 'test-infected' as a human readable alias for 'Test Driven Development' ...
Basically, a "unit test" tests some unit of software, usually a module of some sort. It will run through API's and such to ensure that base functionality is as expected.
Then we have "integration test", where pieces are put together and system is checked for overall operation.
"Regression tests" are those that are done to make sure that things that were once fixed stay fixed, and don't "regress" to be broken again. Often unit tests can be run as part of regression testing.
... I would have to argue that unit tests should have been completed long before getting to 'packaging', and arguably integration tests as well. (I will leave regression testing on one side as I personally think that regression tests need to be more rigorous and should be fully automated, independent of individual developers; and I wouldn't mind if they took hours or days to complete, so I would expect that regression testing is prescribed as mandatory only for release candidates perhaps also being done irregularly during development).
Once one has unit tests in, maximizing their benefit is good. Running all unit tests before checkin is a very good thing. Running them each and every developer build is even better.
I may be mixing two independent points here, but I would explain this in terms such as "Never require your folk to choose between the easy way and the right way".
Urging people to do unit tests may even be counter productive, but showing how to do them and stating that they are done personally before checking in could be a much better way of achieving this very good thing. Care should be taken, however, that we do not break the Inkscape model of "patch first and question later", and also (in my opinion) that we do not dissuade people who wish to contribute to the code, but whose drawing skills are better than their C++; until we have really good extensions and plug-ins systems - a discipline in a mediaeval sense - then people with both drawing and coding skills are very valuable, indeed there should be a Welcome Mat or Red Carpet out for them.
Perhaps the all target should be configured so that a plain make as in:
$ make -sC obj_dir
should imply an invocation of 'make -sC obj_dir check', and if a dev wanted to avoid the 'check' step then he or she would have to specifically ask for 'make -sC obj_dir inkscape inkview'
Test Driven Development goes on to say that you shouldn't bother writing anything that you don't code the unit tests for first. If you can't create a unit test for some function, then you either don't need that function, or don't understand what you're doing.
I would claim to be test-inf.., ahem, fully in favour of Test Driven Development, though probably not an Xtremist, and would merely add that a set of unit tests (of the type we are discussing) focussed on coverage would be very useful indeed to anyone who is considering making changes to part of the code that he or she does not fully understand, which is probably all of us.
(My original point about smoke testing was intended to speak to 'acceptance testing' - the dev certifying that the build was good enough to be worth a tester spending time on - but your points are somewhat more general in that they cover what we do every day).
I respectfully submit these two small patches to the unit test system that make it more effective when building outside the source tree (object dir build):
Index: src/Makefile_insert =================================================================== --- src/Makefile_insert (revision 11475) +++ src/Makefile_insert (working copy) @@ -338,8 +338,8 @@ echo '#define INKSCAPE_VERSION "$(VERSION)"' > inkscape_version.h
test_all_includes = \ - attributes-test.h \ - color-profile-test.h \ + $(srcdir)/attributes-test.h \ + $(srcdir)/color-profile-test.h dir-util-test.h \ extract-uri-test.h \ verbs-test.h Index: src/Makefile.am =================================================================== --- src/Makefile.am (revision 11475) +++ src/Makefile.am (working copy) @@ -232,7 +232,7 @@ $(svg_test_svg_includes) \ $(xml_test_xml_includes) \ $(test_all_includes) - $(top_srcdir)/cxxtest/cxxtestgen.pl --template=selfname.tpl -root -o test-all.cpp \ + $(top_srcdir)/cxxtest/cxxtestgen.pl --template=$(srcdir)/selfname.tpl -root -o test-all.cpp \ $(libnr_test_nr_includes) \ $(svg_test_svg_includes) \ $(xml_test_xml_includes) \
It is possible that there are other patches needed - I haven't been able to establish whether the other lines in 'test_all_includes' need the $(srcdir) pre-pended.
Ben
On Tue, 25 Apr 2006, jiho wrote:
On 25 Apr 2006, at 09:48 , Ben Fowler wrote:
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
Regarding the upload processes, be aware there are two separate processes - one for "official" builds such as pre-release candidates and the releases themselves, and another process for doing automated daily builds.
I (or one of the other Inkscape admins) can set up your sourceforge account, which you'll need to be able to post packages for the first process.
It would be wise to do this, but I don't want to tread on Michael's toes.
Don't worry about treading on my toes. It's better that I'm not the only one able to do this. We should just make sure we know who's doing what come release time, so as to avoid duplication of effort.
Cheers, Michael
On Wed, Apr 26, 2006 at 08:02:21AM +1000, Michael Wybrow wrote:
On Tue, 25 Apr 2006, jiho wrote:
On 25 Apr 2006, at 09:48 , Ben Fowler wrote:
On 25/04/06, Bryce Harrington <bryce@...961...> wrote:
On Mon, Apr 24, 2006 at 02:48:35PM +0100, Ben Fowler wrote:
Regarding the upload processes, be aware there are two separate processes - one for "official" builds such as pre-release candidates and the releases themselves, and another process for doing automated daily builds.
I (or one of the other Inkscape admins) can set up your sourceforge account, which you'll need to be able to post packages for the first process.
It would be wise to do this, but I don't want to tread on Michael's toes.
Don't worry about treading on my toes. It's better that I'm not the only one able to do this. We should just make sure we know who's doing what come release time, so as to avoid duplication of effort.
I want to give a big thank you to ALL the packagers. I hope my earlier comments didn't minimize Michael's work or anyone elses - to be honest I haven't been very good about reading the OSX threads, but I do know the users *really* depend on the work of the OSX packagers, and I've seen that a LOT of work has gone on to get Inkscape on OSX stable and usable.
For the 0.43 release, it'll be great to see how the OSX packaging team works together. It was fun seeing the linux and windows packagers get organized, and I know OSX users expect much tighter, cleaner integration than other platforms, so OSX could be the most interesting packaging challenge yet. :-)
Bryce
participants (6)
-
Alan Horkan -
Ben Fowler -
Bryce Harrington -
jiho -
Jon A. Cruz -
Michael Wybrow