Syslinux - Dec 2003 - Ideas for contrib infrastructure

Especially with Murali's stuff the question about how to handle contrib 
stuff that isn't part of the syslinux core has come up again.

I think it's necessary to make it clear that it's not part of my stuff 
to keep the support load under control.

I see a couple of possibilities:

a) Inclusion with the syslinux source in a contrib/ directory, with 
subdirectories for different components, e.g. 
syslinux-<version>/contrib/autoboot for Murali's autoboot stuff.

	+ Very easy to find.
	- Tied to syslinux release cycle.

b) A separate syslinux-contrib tarball.

	+ Still pretty easy to find.
	+ Not necessarily tied to syslinux release cycle.
	- One more thing to get.
	- No easy way for the user to know ahead of time what
	  this thing contains.
	- Implicit dependency on syslinux tar ball for include files,
           etc.

c) Links on the syslinux page.  In other words, no real contrib 
distribution, but a place to post syslinux additions.

	+ Not tied to syslinux release cycle.
	+ I'm not in the loop for making upgrades/improvements.
	- The least "unified" option.

Again, I'd really appreciate advice.  I think it's wonderful that
we're
starting to see independently developed addons for syslinux, which of 
course was part of the whole idea with the COMBOOT/COM32 API work.

	-hpa

How about the following combination:

* contrib stuff distributed with syslinux, so users will not have to 
keep track which version of syslinux needed ...
* and a link where the latest version may be downloaded is also 
specified. So for those who want to test out the latest, they can do so.

* If the size of the contrib becomes large, then we can think of its own 
tarball.

- Murali

H. Peter Anvin wrote:
> Especially with Murali's stuff the question about how to handle contrib
> stuff that isn't part of the syslinux core has come up again.
> 
> I think it's necessary to make it clear that it's not part of my
stuff
> to keep the support load under control.
> 
> I see a couple of possibilities:
> 
> a) Inclusion with the syslinux source in a contrib/ directory, with 
> subdirectories for different components, e.g. 
> syslinux-<version>/contrib/autoboot for Murali's autoboot stuff.
> 
>     + Very easy to find.
>     - Tied to syslinux release cycle.
> 
> b) A separate syslinux-contrib tarball.
> 
>     + Still pretty easy to find.
>     + Not necessarily tied to syslinux release cycle.
>     - One more thing to get.
>     - No easy way for the user to know ahead of time what
>       this thing contains.
>     - Implicit dependency on syslinux tar ball for include files,
>           etc.
> 
> c) Links on the syslinux page.  In other words, no real contrib 
> distribution, but a place to post syslinux additions.
> 
>     + Not tied to syslinux release cycle.
>     + I'm not in the loop for making upgrades/improvements.
>     - The least "unified" option.
> 
> Again, I'd really appreciate advice.  I think it's wonderful that
we're
> starting to see independently developed addons for syslinux, which of 
> course was part of the whole idea with the COMBOOT/COM32 API work.
> 
>     -hpa
> 
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
> 
>