Re: [stellation-res] The server, and self-hosting

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Sunday, February 09, 2003 9:38 PM
Subject: RE: [stellation-res] The server, and self-hosting


> On Sun, 2003-02-09 at 21:10, Jonathan Gossage wrote:
> > > >-----Original Message-----
> > > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > > >Chu-Carroll
> > > >Sent: February 9, 2003 2:07 PM
> > > >To: Stellation-res
> > > >Subject: [stellation-res] The server, and self-hosting
> > > >
> > > >
> > > >
> > > >So, finally, the Stellation server machine is pretty much ready to
> > > >go. The Eclipse folks have set up the machine, and once I do a bit
> > > >of set-up, it will be unveiled.
> > > >
> > > >Based on my work over the last couple of days, there are a few
> > > >things that I'd like to finish before we really start using it. I'll
> > > >provide my own list at the end of this message, and I'd like to know
> > > >what others think are essential before we start really using it.
(Just
> > > >for info sake: even after we're self-hosting, I plan to mirror
changes
> > > >into the public CVS for backup.)
> > > >
> > > >I'd also like to propose that initially, we not have an anonymous
> > > >account on the server. For at least the first month or so, I'd like
> > > >for people to have to explicitly request accounts on the server. (The
> > > >accounts will be set up with read-only privileges.) There
> > > >are three reasons for this. First, it will somewhat limit the traffic
> > > >pounding on the server. Second, with the ACL support being relatively
> > > >untested, it gives us a bit of added security - if something goes
> > > >wrong, we can tell *who* did it. And finally, it gives us a bit
> > > >more information, so that if a certain user crashes the server, we
> > > >can reproduce the sequence of operations that they performed
> > > >leading up to it.
> > > >
> > > >I've been skimming the code, and the one thing that worries me is ACL
> > > >support. I've written a lot of tests that really pound on the ACL
> > > >support in the repository, but the command line ACL support is
> > > >completely untested. Reading the code, the command-line ACL
> > > >stuff is pretty complicated, and with no tests, I have absolutely
> > > >no trust that it's bug free. So I'd like to do some code cleanup and
> > > >some testing to make sure that it's working correctly.
> > > >
> > > >Our Eclipse support is currently quite weak. The working Eclipse
plugin
> > > >is based on Jim's first attempt, which was done by wrapping the
> > > >command-line in an Eclipse veneer. This was not entirely successful,
> > > >because the command-line and the Eclipse workspace have very
different
> > > >deep assumptions. The plugin mostly works, except that the merge
support
> > > >does *not* use the Eclipse sync view for conflicts. It places a
textual
> > > >conflict marker, just like the CVS command-line, and then Eclipse
> > > >generates a cascade of syntax errors around the marked conflict.
> > > >Personally, I'm willing to live with this in order to get us to start
> > > >using Stellation.
> > > >
> > > >Is there anything that anyone else considers crucial before we start
> > > >up a Stellation server?
> > > >
> > > > -Mark
> >
> > Do you think we have sufficient support to handle code audits at this
point?
>
> We have full branch support. So for doing audited work, we can fork
> branches named after the bugzilla bug that they're related to; check in
> the changes there; and then pass the branch to someone else to be
> committed back into the main branch.
>
> > Will it be possible for interested parties to continue to use CVS if we
> > experience early problems?
>
> I'm planning to do mirroring of changes from Stellation to CVS. If it's
> at all possible, I'd like to avoid the dual-mirroring situation, where
> there are concurrently changes happening in both CVS and Stellation,
> and I need to keep things in synch manually. But the changes will be
> mirrored out to CVS, so that if we experience problems, we can easily
> temporary back out to CVS. I'd just like to be sure to do that as a
> group: if we have insurmountable trouble, we'll all go back to CVS.
>
> -Mark
>
It seems to me that a utility that could import a CVS repository into
Stellation could be useful. Caveat, I have not looked at the CVS API's so I
have no idea how large an undertaking this might be.

Regards

Jonathan