Re: OMAP RedBoot port

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    >> 3) Create an official "package" of the new files and place that
    >> on Delphi's ftp server. I have a document somewhere around here
    >> that describes how to do that. (Did that idea ever catch on --
    >> do people distribute independent packages?)

    Jifl> They do _if_ it's not going in the master repo. Although out
    Jifl> of interest in eCos 2.1 eventually, eCos is likely only to
    Jifl> be distributed as EPK packages!

    >> 4) Request write access to the CVS repository so that I may
    >> commit the changes myself.
    >> 
    >> Obviously, I am exploring option #4 right now, but I would
    >> welcome questions, comments, and/or snide remarks on the other
    >> three options.

    Jifl> This is an interesting point. So far we've restricted write
    Jifl> access to (full) maintainers only. I would be interested in
    Jifl> other maintainer's views on whether we should open this up
    Jifl> more freely now, in the same way as GCC, GDB etc. where
    Jifl> package maintainers are allowed to check stuff in for their
    Jifl> own packages. This wouldn't be the same as a full maintainer
    Jifl> - it's purely an efficiency improvement.

    Jifl> We would also, like GCC/GDB, have a top level MAINTAINERS
    Jifl> file listing the responsibilities. Package maintainers would
    Jifl> be able to commit directly to their "own" packages without
    Jifl> waiting for approval. They can check in patches for other
    Jifl> packages too if they like, but only with approval. *All*
    Jifl> patches must go to ecos-patches in any case.

    Jifl> Comments?

eCos is rather more package-oriented than gcc or gdb. We could end up
with a very large number of maintainers, most of them responsible for
only one or a small number of packages. Each maintainer is a potential
source of security problems, e.g. compromised ssh keys.

In an EPK-based system, it might make more sense to reduce the
importance of anoncvs. All the core packages would still go into
anoncvs, of course, but new ports and device drivers could instead
be provided only as EPK's. Releasing a new version would involve
generating a new EPK, putting it on sources.redhat.com in a write-only
incoming ftp directory, and then moving them to somewhere more public.
The latter could be done by a cron job or a script, possible with a
certain amount of validation by a human. A useful side effect would be
to keep down the size of the anoncvs tree itself: ports and device
drivers already account for a large proportion of the tree, and most
users are only interested in a small number of targets.

In that scenario, it might be better to stick with a small number of
people with write access.

Bart