bulia byak wrote:

OK. I agree. I don't know why it keeps being neglected, but now I want to say this: I will NOT approve going into freeze until we have a static build that can be tested during the freeze.

Someone please make a static build.

Since I made the last one, and I gave instructions about how to do it, I will wait until someone else makes a static build.

After that, I will be happy to make more. It is only a few hours of work. I just don't want to be the only one in the kitchen peeling potatoes. ;-)

Bob

On Mon, 22 Nov 2004, bulia byak wrote:

...

Since I made the last one, and I gave instructions about how to do it, I will wait until someone else makes a static build.

After that, I will be happy to make more. It is only a few hours of work. I just don't want to be the only one in the kitchen peeling potatoes. ;-)

Sure. You did the hard part. Too bad that no one wants to use that and do the easy part.

Ah, hang on. I don't think it's a lack of wanting to do it, I think rather it's just that a few recruitment techniques need to be applied.

1. One thing I've observed time and time again with open source projects is this paradoxical situation where when I need volunteers the most, they're hard to find, but when I figure I'll be doing 100% of the work, they come out of the woodwork (but not always). The rule seems to be, to get volunteers, first reach zen with the idea that you could do 100% of it; volunteers prefer the idea of adding their 10% atop 100% rather than on top of 50%. When you can't commit to that yourself, reduce the scope to what you are comfortable with.

2. I've found that trying to compel help is sort of a square peg in round hole situation. People don't like to get tied up into unpredictably big commitments, but if it looks like something they could just put a little time into, they seem a lot more willing to put a LOT of time into it. I don't know why that is, but there's a lot of evidence that it works this way in open source. Either keep the work optional, or refer to #1.

Instead, focus on the positives. I like to say, "The way to herd cats is to throw mice. Leave the leashes for the dogs." ;-)

3. Lead by example. Or as rejon would put it, "Pick up a shovel". A task that has already been started is a lot easier for a new volunteer to jump into than one that's still in planning stages.

Bob's work to create an example of making static binaries is perfect here. This has removed one of the roadblocks to finding volunteers. Because of this, I expect some others to show interest in helping.

4. Don't be afraid to share the easy tasks. Sometimes it seems like it'd be quicker to do the task yourself than to explain it, yet the extra time can be worth it if it makes the second person more capable to help out in a larger role in the future. If they're interested in helping, it's usually worth it to help them help you.

A collory to this is that be prepared for volunteers to leave the hard parts unfinished; you may have to do them yourself. It sucks, but it happens. Bulia, you're actually better at getting that last 10% out of volunteers than anyone I've seen, so I don't think there's any problem here! :-)

5. Document the heck out of the work. A leading cause of trouble is when volunteers don't have a good feel for what needs to be done. Documentation isn't enough by itself, but lack of information can scuttle the whole thing. Tasks will appear harder than they really are, or you'll attract people without the skills needed to get the job done right.

I suspect this is probably the largest reason why there is trouble raising the troops for creating static binaries. Create a paint-by-numbers todo list for making static binaries, and that'll eliminate this item as an issue.

6. Individual pleas work better than broadcast ones. When I put out general calls for help, more often than not they seem to fall on deaf ears, however when I know someone with the time, skill, and interest in what needs done, then often a direct, polite request for help can stimulate interest. However, realize that people have about a 30% flake-out rate, and try not to hold it against them if they don't follow through - you may need them for another task in the future.

7. Make sure to say thank you. To some people, it seems unnecessary to say anything once the work's done; the performer should know they did a good job when there are no longer any complaints. Yet a lot of people like having some acknowledgement that their efforts made a difference and were not done in vain. The secret is that a show of appreciation takes very little time; it's an extremely cost-effective way of ensuring the guy will help out more in the future.

I think the static binaries are a great solution to the dependency problems I've been worrying will crop up in this release. I'm a little concerned about how long it's taken to get the release out already, and worry that making it a hard condition may delay us a lot more.

Bryce

I'm happy to do it, but I missed the instructions. I haven't had time to search them down. Were they put in the Wiki?

see

http://sourceforge.net/mailarchive/message.php?msg_id=9950297 http://sourceforge.net/mailarchive/message.php?msg_id=9950298 http://sourceforge.net/mailarchive/message.php?msg_id=9948778

And if it's a static build, should it just be tarball?

I'd guess so. At least it should be available as a tarball too even if it is also a RPM.

On Mon, Nov 22, 2004 at 08:16:15PM -0800, Kees Cook wrote:

These discuss building the extra libraries as static. I will try to find time to investigate tonight.

I don't see a way to do this right now. I can create an "inkscape.static" target in the Makefile.am, but even with -all-static added, libtool blows up:

/usr/X11R6/lib/libX11.a(GetDflt.o)(.text+0x9a): In function `GetHomeDir': : warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libX11.a(GetDflt.o)(.text+0xea): In function `GetHomeDir': : warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libxml2.a(nanohttp.o)(.text+0x1729): In function `xmlNanoHTTPConnectHost': : warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libxml2.a(nanohttp.o)(.text+0x1834): In function `xmlNanoHTTPConnectHost': : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x76a): In function `_X11TransSocketINETConnect': : warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

And produces a bad (unfinished?) executable.