Re: Summary of a IRC conversation in #zynot-infra

On 8/10/03 5:42 PM, "Sander Striker" <[email protected]> wrote:
>>=20
>> Zynot-submit?  That's a new one to me ...
>=20
> zynot-commit@
>=20
> This will be the mailinglist receiving _all_ commit messages related to
> any changes in the tree.  There will be seperate mailinglists created
> that just receive changes related to a certain architecture, and possibly
> also lists related to certain (groups of) packages.  That way a developer
> can chose the level of how much he wants to monitor.
>=20

Yes, that makes much sense to me as well, split by subtress (or however the=
y
end up being broken down).

>> I think we really need to unify some of these mailing lists... I'm subbe=
d to
>> quite a few now and more is only going to confuse matters.  What is zyno=
t
>> submit's purpose?  (I don=B9t mean to sound gruff, just asking questions h=
ere
>> ;)
>=20
> There will be more lists.  But I agree that we should be careful of
> wildgrowth.
> We also need a better naming convention.  Prefixing each list with zynot-=
 is
> just plain silly, given they are already in the zynot.org domain.
>=20

Yes, that is my concern as well.  There is quite a lot to follow now, and
given where things are going I'm afraid of things overburdening us too soon
in the process.


>=20
>> Also I think we need to get SVN tested fairly solidly (by that I mean wi=
th a
>> _lot_ of file and some heavy loads) before we start a proper production =
env
>> from it.  I was told by very many people (that I trust in these matters)
>> that we will kill svn dead under the load we are going to generate with
>> multiple trees, etc.
>=20
> That depends.  Connectiva (the distro), seems to be coping well.  Subvers=
ion
> does have performance problems and possible scalability issues, but depen=
ding
> on the usage pattern you may or may not run into them.  The Subversion gu=
ys
> are definitely looking into fixing these problems.
>=20

Yes, it wasn't a shot at svn, but more the fact that we could potentially b=
e
pounding it pretty hard, pretty quickly, and it got much advice to be
careful we don't grind it into the ground.

>> Not being able to even properly test it on anything non-x86 is also a
>> concern for me.  I did manage to get it compiled on ppc (nasty hacking),
>> I've yet to be able to really put it to the test.  I would be concerned =
to
>> commit all my work to something that I may not be able to get it back fr=
om
>> at a later date.
>=20
> If you do a regular svnadmin dump $REPOS > dumpfile, you are always able =
to
> recover your data.  People who are less paranoid can backup their svn
> repository
> using the hot-backup script included with Subversion.
>=20
> Just some quick feedback,
>=20

Thanks for the feedback :)

Mark