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

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Mark Guertin
> Sent: Sunday, August 10, 2003 6:18 PM

[...]
>>    3. Subversion repository is up, but only a few seem to know about
>>       it. Developers should subscribe to zynot-submit mailing list to
>>       see what's going on. (I'm not sure about the status of the
>>       infrastructure, especially whether it's possible to mass create
>>       user accounts with write permissions the the repository, yet.
>>       Mark?)
>
> Zynot-submit?  That's a new one to me ...

zynot-commit@

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.

> I think we really need to unify some of these mailing lists... I'm subb=
ed to
> quite a few now and more is only going to confuse matters.  What is zyn=
ot
> submit's purpose?  (I don=B9t mean to sound gruff, just asking question=
s here
> ;)

There will be more lists.  But I agree that we should be careful of wildg=
rowth.
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.

> We really need to set down a procedure for where/when/how things that _=
all_
> developers need to know get announced.  TO date it's felt more like a
> "scramble for yourself and figure out whats up").

You mean something like announce@ (which should be used for announcements=
 to
the general public), committers@ (reaches all committers, no opt-out), de=
v@
(reaches all committers, opt-in).

>>    4. It was proposed to have another subversion repository
>>       (additionally to the development and IT repositories) for
>>       binaries (stage tarballs for example).

-1 (yes, that's a downright veto).  Binaries should be reproducable from =
the
source in the repository.  That being the case there is no reason why we =
should
version binaries.

> I personally don't like this idea.  We most definitely need a proper
> naming/versioning scheme for releases, and a flat filesystem is proper =
for
> this IMHO.  If there's an SVN repo for it all its going to waste massiv=
e
> amounts of CPU cycles for nothing.  If people are re-releasing the same
> tarballs with fixes, they need a revision/name change anyway...

Right.  You need a proper filesystem layout, naming scheme, and archive
scheme.  If you have that you're set.

> Burying stuff like this is SVN makes things much less accessible, which
> leads me to another point not mentioned ....
>
> We need an svn subtree built.  gforest started on one, but in the wake =
of
> the shows going on it wasn't finished, there are still builds missing f=
rom
> it, any takers to finish this and get it online?  Also posting it to SV=
N is
> probably not a great plan considering it's purpose ;)

It was a good plan.  But, it needs to be finished and released.

> From what I understand we need amir's fixed up svn builds and everythin=
g
> that goes with them (like the custom db4, etc).

So either the correct ebuilds with their dependencies should be published
somewhere on the zynot.org domain with instructions, or, we should give
instructions how to build from source...

> At this point the only way to get a working SVN is to pull and entire o=
verlayed
> tree with amir's gentoo based tree.

Come on.  That's certainly not the only way.  If you download a Subversio=
n
release tarball and read INSTALL you come a very long way.  Especially if=
 you
don't need to build a server.

> This is not a great idea for users of non x86 trees (like ppc).
> Kind of defeats what we are going for here, I don=B9t want to add anoth=
er 20k+
> files for portage/porteus to choke on ;)

Agreed.

> Also I think we need to get SVN tested fairly solidly (by that I mean w=
ith 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.

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.

> 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 f=
rom
> at a later date.

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 rep=
ository
using the hot-backup script included with Subversion.

Just some quick feedback,

Sander