Packaging Argus 3.0 for Debian

[Carter Bullard]

Hey Andrew,
     So we'll go with argus-3.0.0 and argus-clients-3.0.0, for this
first wave of testing and then we'll release it as argus-3.0.2
when its done.  I like the odds are unstable the evens are
stable, or at least some way of distinguishing code.  Does
Debian have something similar?

    I've been swamped, but I'm going to put some effort this
week on the clients.  argus is ready, however, so its just
a little bit of time now.

Carter

On Apr 29, 2006, at 1:06 PM, Andrew Pollock wrote:

> On Wed, Apr 12, 2006 at 09:21:57AM -0400, Carter Bullard wrote:
>> Hey Andrew,
>>    Long time no read, hope all is doing very well for you!!!!!!
>
> Slow and steady.
>
>>    This is a major version number change as its a completely
>> different output format.  The argus and its clients will be
>> backward compatible.  Backward compatible in that they can
>> use existing configuration files and the clients will be able to read
>> previous versions data, but,  2.x clients will be clueless as to how
>> to read 3.x data.  Users will have to commit to a change if they
>> use argus-3.0.  The feature set is not different, but there are a few
>> new features that have crept in, so that's not 100% accurate.
>
> Sure, that's fine. If Argus 3 couldn't grok Argus 2.0.6's data or  
> config
> files then we'd be in a bit of an upgrade mess.
>
>>    With regard to options, we will have a lot of work just to realize
>> whats different, as argus-3.0 was a clean slate implementation,
>> but, again, lets say 80-90% right now is the same.  The output
>> format for some programs will be noticeably different, maybe
>> a column title is sightly different spelling, filter syntax is the  
>> same
>> but maybe a keyword is slightly modified, that kind of thing.
>>
>>    New features, for argus we'll be able to track IPv6 flows, there
>> are 64-bit counter support, and we'll support native 64-bit
>> machines, and we'll support MPLS labels in flows.
>>
>>    For the clients, we'll have a new program, rasplit(), which
>> resembles the unix split(1) program, and is used primarily as a
>> record collector and to support sorting, etc...   The number one
>> program for modifications is ratop(), which should be the data
>> viewer of choice, or at least that is how I want to sell it.  Its  
>> still
>> curses based, but it has a large number of changes to make it
>> useful.
>>
>>    So with all of that, lets just package it as argus-3.0.  The argus
>> is ready for testing, and I'm working on the initial client test  
>> release
>> now, but with the holiday coming up, I probably won't have it
>> ready until after Easter.
>>
>>     And last but not least, its your turn to tell us what would help
>> you, especially with version numbering and installation
>> guidelines, if we're not doing the right thing.
>
> My only request is to keep the version numbers simple and sane. The  
> "fixes"
> suffix and the "rc" suffix made a bit of a mess of things, because
> lexically, "fixes" precedes "rc", when this wasn't the case  
> chronologically.
>
> You could do "rc" again for release candidates, but I think you  
> should stick
> with a 3 part version numbering system for post 3.0 releases, so  
> just use a
> minor revision number instead of "fixes".
>
> regards
>
> Andrew
>

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax