[rt-devel] hacking on rt.

Fri Feb 8 15:01:33 EST 2002

I have worked on and off with aegis for about 2 years now.  I have been a 
careful watcher of the mailing list for 1.5 yrs.

I am in the process of moving a substantial project onto it. 3/4M LOC. 16 
builds on 5 architectures etc. etc.

I will say it takes an investment, but it can be well worth it depending on 
your goals.

I'm not sure exactly what your problems are with the remote development 
issues but there seem to be a lot of people making it work with aegis.

aedist seems to be what most people use

So, under one possible scenario you (Jesse) would set up an aegis project, 
release some version of RT 2.0.X and place for public download: the tar 
installer as well as the .ae (aedist file from "aedist -send -baseline") of 
your COMPLETE repository. If someone has a change they can grab your 
baseline aedistfile (and any external dependencies perl, etc) and set up an 
aegis build environment of their own.  Then they (the contributor) can 
start a new change (or branch) and modify the code as they see fit. Go 
through some amount of process..(testing ;-)..and eventually end the change 
(or branch).  They (the contributor) can then wrap up that change, JUST the 
change(or branch), and send that back to you via "aedist -send -p xxxx" .

Then you (Jesse) can do an "aedist -receive" that will create a new change 
for you (number will be different than the change number of originator) 
that you can look over and then choose to integrate into your "golden" 
baseline.

After making all of your internal changes and possibly accepting external 
changes (via "aedist -receive") you can then end the branch that 
corresponds to the next release, and release the new version of RT (2.0.Y). 
It's tar installer, .ae of the entire project ("aedist -send -baseline") 
and a .ae of the differences since the last version of RT("aedist -send -p 
xxxxxx") can then be posted for everyone to consume.

Hot fixes can be done in the same way, just aedist the change that includes 
the hotfix.

Anyway this is just a re-iteration of what is already in the Users Guide 
(Section 11) Geographically distributed development.

One advantage to aegis's change "package" is that you do not need to be 
connected to the repository to obtain updates.  I.E. company X keeps a copy 
of a source repository behind a firewall, doing a CVSUP is impossible (so 
say-Eth the Sys-Admin anyway ;).  With the "package" files, the person 
running the main repository can just E-Mail,HTTP download,FTP 
download,Sneaker-Net  the .ae files to  the client. Basically, however you 
could send a patchfile you can send a "smarter" patchfile, the aedist file.

I don't know of a really strong reason that anyone would need to have 
direct access to the repository.  The only two I can think of right now is 
if you want someone outside of BPS (Best Prac...) to be an "integrator", or 
be able to create change requests.  I am making a HUGE assumption that you 
(Jesse) or a BPS employee would be doing ALL of the go/no-go integration 
decisions. As well as deciding what reported bugs get assigned to aegis 
change requests.

Otherwise, let everyone maintain their own aegis project that mirrors yours 
through the use of the .ae (baseline) and .ae (updates), this is similar to 
doing a CVS get and CVSUP. You can keep everyone on the bleeding edge by 
sending a .ae for each change that you complete, heck send that to the 
rt-devel list instead of/along with patchfiles.  Others that are 
contributing can do the same (post .ae's to the list) and everyone can 
choose to stay on edge or "pick and choose", whatever.

This is a bit different paradigm than CVS and patchfiles, but I don't think 
its all that much different/worse.

Aegis seems a bit to wrangle with at first, the price you pay for all of 
it's checks-and -balances I guess, and it is primarily UNIX, don't know how 
this affects the community. But it can do a lot to help enforce "rules" of 
development and can do even more to keep from shooting yourself in the foot 
(figure of speech) if you set it up to do so. Let me also mention you can 
configure it to be as "loose" as you want as well. For instance I have 
personal projects where I play all of the aegis roles and do none of the 
testing etc. but I get all of the metrics collection, reports, etc. etc.

There has been lots of traffic about aegis and distributed devel. Many, 
many different ideas, I think Peter mentioned he had an idea about making 
aegis look like a CVS server so people could get the code with a CVS 
client, but I don't know if any work is being done or will be done.  But I 
think with the kind of quality people there are in the aegis community 
something will come about.

There is also lots of work being/been done with making aegis work in 
co-operation with CVS.

If CVS just isn't cutting it, but you want a solution that is similar. I 
think the next best answer is Perforce http://www.perforce.com.  It at 
least groups many of the logical things together that CVS doesn't.  But 
there again, at some point you'll need to connect to a repository directly.

Sorry this is so long.

Anyway, these are just my rambling thoughts.
Others may have much more elegant solutions.

I hope it helps answer a question or two or, more importantly, spurs a 
question or two.

Jesse, thanks again for RT.

Joshua Johnson

--On Friday, February 08, 2002 12:20:48 PM -0500 Jesse Vincent 
<jesse at bestpractical.com> wrote:

>
> On Fri, Feb 08, 2002 at 11:02:02AM +0200, Fabian Ritzmann wrote:
>> Two open-source systems you might want to consider:
>>
>> Aegis: http://aegis.sourceforge.net/
>> - Mature, complete configuration management system. Unix only, but WWW
>> interface.
>
> *nod* I actually spent a bit of time with aegis a while ago and decided
> that its manual was too obtuse and it was too process-bound.  The fact
> that it doesn't have a way of allowing remote developers to interact with
> a repository without local shell access also bothered me.  But over the
> past day or two, I've been re-familiarizing myself with the package and
> think I see ways around most of my major issues with a little bit of
> scripting.
>
>>
>> Subversion: http://subversion.tigris.org/
>> - Very interesting architecture, but still pre-alpha.
>
> A friend of mine hacks on subversion. It looks very interesting, but still
> isn't quite ready for primetime and it doesn't have one of the two
> features that I really really want: the ability to do distributed
> repositories cleanly, so I can work on a branch on my laptop (without
> net) , checking in every time  I hit a micro-milestone and then merge up
> to the "main" repository when I  finish.
>
>
> I'm currently leaning toward spending a couple days playing with an aegis
> repository and the RT 2.1 codebase. The basic plan would be to leave the
> 2.0 branch in CVS, but to do new development in the new VCS.  Has anyone
> here worked with aegis?
>
> 	-j
>
> --
> http://www.bestpractical.com/products/rt  -- Trouble Ticketing. Free.
>
> _______________________________________________
> rt-devel mailing list
> rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel