[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sponsors.

> On Fri, 25 Aug 2000, Chris Coleman wrote:
> > 	Listed several features that we want to incorporate from each
> > 	 project.
> I must have missed the list of things that we can take in from FreeBSD,

Satoshi San, can you give us a list of features that FreeBSD has that
should be incorporated into this project?

> and I also didn't get some questions I had on the OpenBSD features (what
> make enhancements, what is make-maker) answered yet. 

Todd, Chris, will you answer these questions please?

> Sorry if I missed these, someone please forward them to me. Thanks a lot!
> > What do we need to do next?
>  * Define more things that we want and not want

Hubert, will you maintain this list?  I will post it to the web page when
it is ready.

>  * Get our shovel and bucket, enter the sandbox and beat on each other
>    long enough to decide on which system to start with.
>  * Hash out minor details like directory structure and some other
>    guidelines.
>  * Find someone to do an initial import (bsd.*.mk, pkg_*, ...)
>  * See if there's someone left to add the remaining features
>  * Get the remaining features implemented in bsd*mk, pkg_* and the
>    pkgs/ports themselve

These sound like we need to have our CVS server setup.  I'll see if I can
hurry things up...

>  * Announce
>  * Cheer, party, dance
>  * Think about how to integrate this into existing OS'. I think something
>    like the KAME project can act as an example here.

Would it be possible for each group to just maintain a CVS checkout of our
CVS tree?  The cvs checkout could update only the directories that
completed a successful build.  Then at release time they could cvs tag
that checkout and use it to build packages.  I want to avoid branching
this project.

Is that senario possible, or am I dreaming?

>  * Maintain, evolve, enhance
> > Do we need to write up a "white paper" to give the project some guide
> > lines?  IF so, I will pay someone to do it.
> We will definitely need guidelines. See part II of 
> ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/Packages.txt for guides on
> one pkgs system - annotations with differences to another system will be
> needed as well. Also, I can imagine a chapter about what features to
> expect from the host OS, which features to treat as optional, how to
> handle  missing features, and what to do to get them (if).

When we get this project ready to roll out, I will pay someone to write a
series of articles documenting how to use the project.  Both for users
compiling packages and for developers creating packages.


>  - Hubert
> -- 
> NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!
> To unsubscribe: send mail to <majordomo@unixathome.org>
> with "unsubscribe bsdports" in the body of the message

To unsubscribe: send mail to <majordomo@unixathome.org>
with "unsubscribe bsdports" in the body of the message