On Thu, 1 Mar 2001, Craig R. McClanahan wrote:
> Ted Husted wrote:
>
> > "Geir Magnusson Jr." wrote:
> > > However, if they are 'independent entities', it is missing one thing -
> > > the grouping of committers. I still chafe at the one large committer
> > > group that spans every package idea. See 'Subproject Guidelines' #15 in
> >
> > I think it's mainly a security/human labor issue, Geir. There's a
> > certain amount of work involved in setting up a new CVS repository, and
> > adding committers to it. Until we can show cause, I think the best thing
> > to do is use the status file to track the committers for each package,
> > which will give us a leg-up in case we want to create more repositories
> > later.
> >
> > I think the mailing lists, on the other hand, are easier to create, and
> > are also self maintaining -- people can sub and unsub themselves. So,
> > its easier to keep those separate from the beginning.
> >
>
> Speaking as the person that would be responsible for both of these things,
> you've got the effort required totally backwards :-)
>
> Setting up a CVS repository is very straightforward (< 3 minutes). Setting up
> a mailing list is much more involved, and causes incremental overhead not only
> on the Apache mail server (which serves all *.apache.org mailing lists) but
> also on the nice mailing list repository sites that are responsible for
> archiving our lists for us.
>
With that in mind I am +1 on shared cvs, +/-0 on creating new mailing
lists now, +1 for keeping things on this list for at least a short while
longer. Right now the importance of developing the process/infrastructure
is pretty much running alongside that of the first project ( I think we
got consensus on DBCP? ). Having this one mailing list for the time that
this is largely an internal project can help debug the process and
community issues as they arise ( In a way it already has started to fill
this need ). As the need develops and a significant amount of user
questions come in, we can setup a new mail-list on a case by case
basis or develop a better understanding of when/where we need to
split the stuff off.
> >
> > The ASF is very security-conscience. If things were different, we could
> > just install a copy of SourceForge and let that maintain most of this
> > for us ;-)
> >
> > -T.
>
> Craig
>
>
>
David
