Re: [ jEdit-devel ] Build requirements and process

[Slava P. <sl...@je...>]

On Thu, May 15, 2003 at 01:33:12AM -0700, mike dillon wrote:
>                  Answers to Stefan, Calvin, and Robert
> 
> 1. Letting plugin authors release their own plugins, getting rid of the
>    release manager altogether, "automating" plugin distribution
> 
>    I don't think this should happen. At the very least, I believe the
>    release manager(s) should be there to perform quality assurance.
>    Since one of the requirements for releasing a plugin to PC is that
>    end users must be able to build it, the QA process should include the
>    release manager(s) building the plugin for release themselves.

I agree.

> 2. Standardizing directory structures, generic build file
> 
>    I think that a generic build file would work for nearly all plugins.

I don't think a standard build file is necessary, as long as plugin build.xml's
have reasonably standard target names so the packagers don't have to examine
each build file that comes along in detail. I will update the build requirements
file right now.

> 3. Plugin release queue, notification of plugin readiness
> 
>    I agree with this one. In fact, I've wanted to implement this on
>    Plugin Central for a few months at least. I don't think the work
>    involved is too difficult, so it will be one of the things for me to
>    do before the transition.

We could have new plugin submissions be added to a new tracker on SourceForge.
Then plugin packagers could add comments, and close the request when the plugin
is released. But I find e-mail adequate.

> 4. Compatibility kit, automated certification
> 
>    Excellent idea. I'd say the requirements for this kit are pretty well
>    defined in Slava's requirements document, hopefully with my revisions.
>    Any further requirements can be added later.
> 
>    Not to get ahead of ourselves, but I see this kit being a plugin
>    itself, running inside of jEdit. I see it being run by the
>    developers, the release team, and whoever else thinks it might be
>    interesting. It should run against the compiled plugin and/or its
>    source code.

How would you automate something like this?

> 5. Automated JUnit testing
> 
>    On this one, I wouldn't go beyond a recommendation in the build
>    requirements that plugin authors include an Ant target called "test"
>    for running their top-level test suite in the Ant textui Runner, if
>    they have any. I don't know if the release team should be required to
>    run tests if they're there (I could see both sides being argued).

As a packager I don't want to run a zillion third-party tools for building
plugins. I think its up to the plugin developer to run tests if they want to.

> Side note: One thing I feel strongly about is that plugins should
> continue to be released in batches, even if a batch is released every
> day. I think one Plugin Central release announcement per day should be
> the limit.

I think one batch every 1-2 weeks is more reasonable, so that plugins in CVS get
at least a few days of testing time before being released.

>                                 Workflow
> 
> This is the workflow I envision for the plugin release process. This
> process involves:
> 
> * The plugin developers
> * The plugin release team (~4-5 people)
> * The plugin release manager(s) (~1-2 people, included in the 5 above)

I don't even think we need that many... maybe 3 packagers in total.

> I foresee different builders having responsibility for different sets of
> plugins or different jEdit versions (stable v. devel).

I'd prefer each builder to test against both 4.1 and 4.2.

> 1. Fetch the source code for a plugin from the queue
...
> 8. Build Plugin Central source and binary packages

Of course its much more complicated than this if the source has a non-standard
directory layout.

> I disagree. I have always followed the convention that plugins on Plugin
> Central will build in the "system" plugin directory and that the
> build.xml will fully specify the necessary classpath. This (in theory)
> means that someone should be able to build a plugin from Plugin Central
> by simply invoking ant on the default target of the plugin's build.xml.

Well I have all my plugins except the bundled ones in my user directory. It
makes it easier when releasing new jEdit versions -- I just tar up my CVS tree
without the CVS directories. I don't this feature is particularly useful.

How about a jEdit plugin that runs AntFarm with a class path configured for a
specific plugin?

> Under the "Build tool" section, I would make requirements about the
> names of the required targets:
> 
> * "dist" - for the main target
> * "docs" - for the documentation building target, if there is one (it
>   should use the <ant-call> technique illustrated in plugins/template.ant
>   in the jEdit CVS)

A lot of plugins using docs-xsltproc and docs-xalan. I would prefer the names
which are standard right now.

> * "clean" - I'd make this a requirement, since this needs to be done
>   before building source packages for PC

I always do rm `find -name \*{~,.class}` anyway.

> Other than those few minor(?) changes, I think the document looks
> ready to go. I'll put whatever version you want on Plugin Central,
> Slava.

I've attached a new version with this email.



-- 
Slava Pestov