Thank you Timothe for maintaining the extensions in SVN, this makes it easier for all, including you. Sorry it was a "miserable experience" to learn the build stuff. I it is documented, but if you feel not sufficient you can enhance as needed. Feel free to ask too.

You have a ContactAuthorFirst modification policy. I'd like to help out on the plugin docs. Is it OK to do that directly in SVN?

I don't know about easier - midnight meetings & feature proposals to work on my own code doesn't meet my definition of that But yes, svn is a good thing (and I use it locally).

The build/create installer doc was hard to find. (BuldContrib was the best I found.) It was confusing. I had permissions problems that made the tool blow up with stack traces. (Turns out that sudo -u on all the commands helps a lot.)

The tools & doc seemed to suggest that the tools wanted to create MANIFEST/DEPENDENCIES -- and that I was supposed to create them. Never succeeded in getting the tools to do it - anyway, for IpPlugin, they were trivial to write by hand.

The tools seem to want a topic template so they can automagically add dependencies and other "variables". I never figured out to to make that work right; where the template topic lives directory? Is it supposed to be in svn, or the output? I stuck with the topic I wrote.

Testing the kit doesn't work as documented - it wants to download the old kit from twiki.org. Finally figured out that putting the kit in the directory I was supposed to be in while testing caused it to ask whether I wanted to use it. Wanted to do a test upload to my local Sandbox, as I didn't want to put anything with problems into twiki.org's revision history. Never got that to work - some random error from the tools.

"Copy from some existing plugin and modify" was less than helpful - every one I looked at had some special oddity - I couldn't tell what was required generically vs. what was unique without research. I did not want to make a lifetime study of this, I just thought I should supply an installer. I thought it was a 20 min task; I spent half a day.

Where are the topic(s?) necessary to have a local "test upload" repository? Why, if install is supposed to be automated, doesn't it enable the plugin (if it's a simple plugin), or print out the URL for Configure (if the plugin ships with a configure extension .spec)? sed -i.bak lib/LocalSite.cfg -e'/^\$TWiki::cfg{Plugins}{XxxPlugin}{Enabled}/d' -e '/^1;/i$TWiki::cfg{Plugins}{XxxPlugin}{Enabled} = 1;'"

I kinda sorta got to something that seemed not totally wrong, and timed out.

WRT your offer to help with plugin docs: I never turn down help - but what needs doing?

If you mean the Off-line task framework, as discussed in the release meeting: I'm counting on it. (I don't think of it as a plugin.) But we should talk about the mechanism. My original idea was to keep the docs with the code - my Install has a gendoc command that (directed by MANIFEST) walks thru the sources and extracts what it thinks is doc. There are tags that specify the order in which they're to be assembled - since there are so may source files, a simple POD extract isn't enough. It may need a little refinement to separate developer from user content. Or if it ends up in more than one topic. Best way to reach me is my acm e-mail.

I added a somewhat more clever DEPENDENCIES builder to the task framework. see tools/builddep, checkin 23538. Somewhat better than the 1-liner, it knows enough to recursively scan files in a package (but not files included by the package), and it doesn't actually do an eval'd require.

It would be a good start at making building install packages easier.

It has a tendency to find more than it should; to dial it back, it consults TWiki's DEPENDENCIES and omits files shipped with the core - unless there's a conflict.

Perhaps it will save someone else some misery, while I wait for my other questions to be answered.