Mailing List Archive

On Sat, Aug 02, 2003 at 07:14:48PM +0100, Paul Jakma wrote:

> any order of business? :)

Perhaps later -- I'm installing zebra-pj (or, I guess I should say quagga
now) on two brand new machines as we speak, for a network that should become
live on Monday. Who knows what I'll encounter :-)
--
Niels Raijer | "For every choice that ends up wrong
niels@fusix.nl | Another one's right
http://www.fusix.nl | A change of scene would sure be great"

On 2 Aug 2003, Paul Cammidge wrote:

> Well, perhaps its prematuture, but how about letting RedHat (and
> others) know about the fork. I really dont know what the procedure
> is, but it would save us a lot of effort if they shipped the new
> code.

AFAICT their zebra maintainer does appear to keep an eye on whats
going on, at least the RH zebra RPM has quite a few of the critical
bug fix patches applied.

> Also, the name should probably be changed in the code at some
> stage,

possibly.

> and maybe a new version number and something in the documentation
> (if it hasnt already happened).

I intend to release Quagga 0.94 soon. If there are no show stopper
bugs, then 1.0.

> Paul

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Documentation is like sex: when it is good, it is very, very good; and
when it is bad, it is better than nothing.
-- Dick Brandon

On 2 Aug 2003, Paul Cammidge wrote:

> oh, i notice that the "reply-to" address on the mailing list is not
> set to the mailing list.

Nope it isnt.

> i dont know if this was deliberate, but i like to be able to reply
> to the mailing list directly.

Well, I tend to subscribe to the 'Reply-To munging considered
harmful' school of thought:

http://www.unicom.com/pw/reply-to-harmful.html

All decent email clients, and even most bad ones, provide ways to
choice whether to reply to all or reply only to author.

> paul

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
It's not hard to admit errors that are [only] cosmetically wrong.
-- J.K. Galbraith

Paul Jakma wrote:

>>i dont know if this was deliberate, but i like to be able to reply
>>to the mailing list directly.
>
>
> Well, I tend to subscribe to the 'Reply-To munging considered
> harmful' school of thought:
>
> http://www.unicom.com/pw/reply-to-harmful.html
>
> All decent email clients, and even most bad ones, provide ways to
> choice whether to reply to all or reply only to author.

I have no clue: would the mail server avoid distribution of a message to
some subscriber if that subscriber is already in the the recipient list
of the message? (I guess so, otherwise an author would have received two
copies of each reply message, ha?)

Another technical question: any particular reason for a capitalized
notation of '[Quagga-dev/users]' in the subject lines? (and not
'[quagga-dev/users]'?)

BTW, congratulations! ;->

Gilad

Gilad Arnold wrote:

> I have no clue: would the mail server avoid distribution of a message to
> some subscriber if that subscriber is already in the the recipient list
> of the message? (I guess so, otherwise an author would have received two
> copies of each reply message, ha?)

I meant the list server, of course.

On Sun, 3 Aug 2003, Gilad Arnold wrote:

> I have no clue: would the mail server avoid distribution of a
> message to some subscriber if that subscriber is already in the the
> recipient list of the message?

it can do. in fact, if you go and login to your mailman user
subscription page for quagga-users you can set whether you want
mailman to deliver list mail to you for which you are on the To list
or not.

Ie you can configure whether mailman should supress delivery for
mails you obviously already will have.

> (I guess so, otherwise an author would have received two copies of
> each reply message, ha?)

not unless the author sends to himself too :)

but the recipient might receive twice, yes. However, the recipient
may /want/ this. Eg, i filter all my list email. I mightnt check a
list regularly. However, if someone replies to me i will get a copy
in my INBOX and i will see it straight away. (and of course the
second copy (via the list) but that will be filed in my quagga-users
mailbox.

So i find it convenient to get 2 copies, if someone replies to me.

(and i hate lists which set reply-to to list because i am denied
this. the choice is made for you. with mailman list, the choice is
yours).

> Another technical question: any particular reason for a capitalized
> notation of '[Quagga-dev/users]' in the subject lines? (and not
> '[quagga-dev/users]'?)

Mailman capitalises it, but i can change it if needs. why? :)

> BTW, congratulations! ;->

pah.. i'm just the patch monkey. :)

speaking of patches, your recursive patch would be /really/ nice to
have ported to zebra-pj^WQuagga :)

> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The first duty of a revolutionary is to get away with it.
-- Abbie Hoffman

Paul Jakma wrote:

> Ie you can configure whether mailman should supress delivery for
> mails you obviously already will have.

Ah, thanks, that's what I missed. (Please ignore my last mail to you
from 2 minutes ago, then...)

>>(I guess so, otherwise an author would have received two copies of
>>each reply message, ha?)
>
>
> not unless the author sends to himself too :)

By author, I meant the originator of a thread, for example. Nevermind... ;->

...
> Mailman capitalises it, but i can change it if needs. why? :)

Less pixels on my mail client window... (just a matter of taste, I guess)

>>BTW, congratulations! ;->
>
>
> pah.. i'm just the patch monkey. :)
>
> speaking of patches, your recursive patch would be /really/ nice to
> have ported to zebra-pj^WQuagga :)

Yeh, I should port it soon, however I definitely think it isn't complete
and shouldn't be included in a distribution of any kind, especially with
respect to memory behavior and overhead. I would like to revise it more
cleverly.

And, speaking of patches, few questions/thoughts:

- are we/you going to form some well-known hierarchy (in the positive
sense, of course) of patch reviewers assigned the various software
components? Or are we going to be fully distributed (almost everyone
submits almosts anything)? Or centralized (one commits everything)? In
any way, since my field of "expertise" is the routing engine itself
(zebra), I may serve as a patch reviewer for that component (one of
many, of course)

- more on patches/extensions: what would be the guidelines you'd expect
a patch to have before being "certified" for CVS? Things that come to
mind with regard to this question: consensus (or majority) among
reviewers, modularity (i.e. using configuration-derived compilation
switches when possible, proper abstractions, etc), efficiency (to what
extent?), coding conventions and/or style (what are they, apart from
being Kunihiro-like? ;-> ), and so on. I believe it's high time we setup
those decisions, before bulks of code start coming in...

- even more about patching: IMO, it's truely fundamental for quagga to
catch up with zebra patches, if and when they occur (since these are
rather rare occasions, it shouldn't be too difficult). But, besides
tracing, this principal (assuming it is agreed upon everyone), suggests
that quagga should part from zebra as *least* as possible, with respect
to code structure, naming (files, functions, variables, constants,
enumerators); furthermore, such approach implies that extensions to
current code should be done in an accumulative fashion, rather that a
destructive one. I'm not sure this is acceptable on others, is it?

- version control / branching policy? (no clue, no proposal either)

To sum up, I truely believe that -- since quagga is a real community
maintained package (in my mind, at least) -- there needs to be some sort
of a manifest, easily accessible from the webpage, which defines all
policies and guidelines with respect to development.

Okay, waiting for flames... ;-o

Gilad

>-----Original Message-----
>From: quagga-users-bounces@lists.quagga.net
>[mailto:quagga-users-bounces@lists.quagga.net]On Behalf Of Gilad Arnold

>- are we/you going to form some well-known hierarchy (in the positive
>sense, of course) of patch reviewers assigned the various software
>components? Or are we going to be fully distributed (almost everyone
>submits almosts anything)? Or centralized (one commits everything)? In
>any way, since my field of "expertise" is the routing engine itself
>(zebra), I may serve as a patch reviewer for that component (one of
>many, of course)

If we go to a single person committing everything, we are going
right down the road we just got off of.

My vote is that like the FreeBSD Project, a list of committers be
drawn up, the list members be selected by vote of the existing
members. Anyone can request (or be drafted in) to be a committer who has
shown
active participation on the quagga list for a specific time period.

The code maintainer's required tasks ideally should be mainly that of the
care
and feeding of the CVS machine, holding votes, booting off committers who
trash the playhouse, etc. Also, to do this
right you must have 2 development trees - a "release" tree where the
code maintainer once every few months does a code freeze on the
"development" tree for a few weeks, the beta testers have at it,
then makes a copy of the development tree to the "release" tree

Let's show Kunihiro how it's supposed to be done!

>
>- more on patches/extensions: what would be the guidelines you'd expect
>a patch to have before being "certified" for CVS? Things that come to
>mind with regard to this question: consensus (or majority) among
>reviewers, modularity (i.e. using configuration-derived compilation
>switches when possible, proper abstractions, etc), efficiency (to what
>extent?), coding conventions and/or style (what are they, apart from
>being Kunihiro-like? ;-> ), and so on. I believe it's high time we setup
>those decisions, before bulks of code start coming in...
>

Basically, anything goes in the production tree. Keep in mind if
a committer submits a patch that is obviously horribly wrong, with
CVS it can be backed out. This is where things like automated
nightly builds of the production tree can be used to catch the
really screwed up stuff. But good committers should be able to
catch this stuff.

>- even more about patching: IMO, it's truely fundamental for quagga to
>catch up with zebra patches, if and when they occur (since these are
>rather rare occasions, it shouldn't be too difficult). But, besides
>tracing, this principal (assuming it is agreed upon everyone), suggests
>that quagga should part from zebra as *least* as possible, with respect
>to code structure, naming (files, functions, variables, constants,
>enumerators); furthermore, such approach implies that extensions to
>current code should be done in an accumulative fashion, rather that a
>destructive one. I'm not sure this is acceptable on others, is it?
>

It is just going to be tremendous work to try to "sync" to the
original Zebra. Plus there's 2 other issues:

1) It dilutes "The Quagga project" control over copyright to continue
to pull in changes from Zebra

2) With the zebra.org community gutted by Quagga, it is going to
remove any source of patches that Kunihiro was getting.

Ted

>- version control / branching policy? (no clue, no proposal either)
>
>To sum up, I truely believe that -- since quagga is a real community
>maintained package (in my mind, at least) -- there needs to be some sort
>of a manifest, easily accessible from the webpage, which defines all
>policies and guidelines with respect to development.
>
>Okay, waiting for flames... ;-o
>
>Gilad
>
>
>_______________________________________________
>Quagga-users mailing list
>Quagga-users@lists.quagga.net
>http://lists.quagga.net/mailman/listinfo/quagga-users
>

On Sun, 3 Aug 2003 02:10:10 -0700
"Ted Mittelstaedt" <tedm@toybox.placo.com> wrote:

> If we go to a single person committing everything, we are going
> right down the road we just got off of.
>
> My vote is that like the FreeBSD Project, a list of committers be
> drawn up, the list members be selected by vote of the existing
> members. Anyone can request (or be drafted in) to be a committer who has
> shown
> active participation on the quagga list for a specific time period.
>
> The code maintainer's required tasks ideally should be mainly that of the
> care
> and feeding of the CVS machine, holding votes, booting off committers who
> trash the playhouse, etc. Also, to do this
> right you must have 2 development trees - a "release" tree where the
> code maintainer once every few months does a code freeze on the
> "development" tree for a few weeks, the beta testers have at it,
> then makes a copy of the development tree to the "release" tree
>
> Let's show Kunihiro how it's supposed to be done!

I see the quagga project highly equivalent to linux kernel. In fact you need
people that know the various hw platforms quagga runs on. Kunihiro always spoke
about patches not tested on other hw then the submitters'. Though I doubt the
argument a bit, there is _some_ truth in it, namely the project needs a
diversification (does this word exist? I'm no native) into:

1) platform independant code
2) architecture specific "glue code"

throughout all the daemons. This would imply you need people for every arch and
people for independant parts.

Your thoughts?

Regards,
Stephan

Ted Mittelstaedt wrote:
>
>>-----Original Message-----
>>From: quagga-users-bounces@lists.quagga.net
>>[mailto:quagga-users-bounces@lists.quagga.net]On Behalf Of Gilad Arnold
>
...
> My vote is that like the FreeBSD Project, a list of committers be
> drawn up, the list members be selected by vote of the existing
> members. Anyone can request (or be drafted in) to be a committer who has
> shown
> active participation on the quagga list for a specific time period.
>
> The code maintainer's required tasks ideally should be mainly that of the
> care
> and feeding of the CVS machine, holding votes, booting off committers who
> trash the playhouse, etc. Also, to do this
> right you must have 2 development trees - a "release" tree where the
> code maintainer once every few months does a code freeze on the
> "development" tree for a few weeks, the beta testers have at it,
> then makes a copy of the development tree to the "release" tree
>
> Let's show Kunihiro how it's supposed to be done!
>

I like the committer concept and code maintainer as well. The most
important criteria for the committers list are, that they need to be
excellent developers and architects, a distributed mastermind so to
speak, maybe a group of 3 for the very beginning.
I'd just like to point out one issue: There was disharmony on other
groups about what is considered an "active or valuable
contribution/contributor", which always is in the eye of the beholder I
guess. The sheer volume of a person's postings is not necessarily a
quality or committment criteria, we don't want to upset
knowledge-lurkers :-). We set the tone here for the future, so let's all
consider this a delicate issue.
I'd suggest for the release cycle
to stick to the numbering of the Linux kernel. How about a patch freeze
as of August 1st 2003 for Paul's patch collection? A review of the
patches submitted and a release as 1.0rc1 which should asap lead to 1.0
late August?
1.1 would be the development branch, then 1.2pre, 1.2rc and 1.2 as next
stable release, makes sense?

Regards,
Gernot

--
Dipl.-Ing. Gernot W. Schmied, MS Network Architecture & Operations
Senior Strategist Research Group
mailto:gernot.schmied@nanorg.org http://www.nanorg.org
PGP Fingerprint: 5D70 5690 47DA 9A21 D07E B9EE C764 C9B7 9B64 B27E

On Sun, 3 Aug 2003, Gilad Arnold wrote:

> Ah, thanks, that's what I missed. (Please ignore my last mail to
> you from 2 minutes ago, then...)

:)

NB for list users: Mailman tries to be clever - if it sees that a
subscriber is already specified in the To or Cc field of a post,
mailman will (by default) /not/ send the post to the subscriber.

This means that if you post to the list and someone replies to you
and to the list (generally a good thing), Mailman will see you should
already have a copy (sent to you directly) and not send the list copy
to you.

Note that this behaviour is configurable in your user preferences
(see the 'Avoid Duplicates' option).

If you dont filter your email, you probably want it on. If you
diligently filter email, you might well want this option off.

/end list-ministrivia

> Yeh, I should port it soon, however I definitely think it isn't
> complete and shouldn't be included in a distribution of any kind,

yes, i'd agree. needs testing and porting (if that's possible) to the
other methods.

> especially with respect to memory behavior and overhead. I would
> like to revise it more cleverly.

look forward to it :)

> And, speaking of patches, few questions/thoughts:

all very good questions.

> - are we/you going to form some well-known hierarchy (in the
> positive sense, of course) of patch reviewers assigned the various
> software components? Or are we going to be fully distributed
> (almost everyone submits almosts anything)? Or centralized (one
> commits everything)? In any way, since my field of "expertise" is
> the routing engine itself (zebra), I may serve as a patch reviewer
> for that component (one of many, of course)

Very good questions..

- hierarchy, nah.. i think a meritocracy would be better. (bear in
mind, i'm just the patch monkey).

- fully distributed / centralised commits? Well, imo CVS write access
needs to be strictly controlled. Either you have one person with
impecable taste and unrivaled technical ability (ie the Linus model)
or else there needs to be some kind of good review scheme for
patches and patches go in by consensus. I dont know whats best
(though i'm pretty sure we dont have a Linus :) - so we'll need to
come up with something).

what would you suggest? I'd steer towards the consensus approach.

Though, I'd still prefer to remain flexible. Ie strike something of a
balance between the Linux model - various people maintain their own
trees, honing patches and submitting them to linux-kernel and Linus,
where they get discussed and eventually accepted (or not) - and the
BSD model - hierarchical, developers who have commit access,
developers who do not.

For the Linux model, we dont have a Linus. And we dont have a lot of
developers either, the zebra.org 'wall' probably turned a few away.

For the FreeBSD model, there isnt much of a track record to go on -
Noone has really had the chance to demonstrate what they can do yet.

What I would suggest, at least for the short-term, is to continue on
as before. Ie i decide :). I think I'm amienable to listening to
others opinion on suitability of patches, I think i'm reasonably good
at following arguments (once they're presented to me) - i've had to
revert patches before when people have pointed out deeper flaws. So,
lets for the moment continue on on the basis of discussing patches
and if i guage consensus is 'patch is good' i'll commit, if not i
dont.

Then from this, some process will hopefully crystalise that we can
put on a more formal (but not too formal) basis.

> - more on patches/extensions: what would be the guidelines you'd
> expect a patch to have before being "certified" for CVS?

good question. Consensus would be the prime factor imo.

> Things that come to mind with regard to this question: consensus
> (or majority) among reviewers, modularity (i.e. using
> configuration-derived compilation switches when possible, proper
> abstractions, etc), efficiency (to what extent?), coding
> conventions and/or style (what are they, apart from being
> Kunihiro-like? ;-> ),

indent -nut style. Ie GNU style, /spaced/ indents (*not* tabs).
(actually i prefer Linus style indentation, 8 char /tabbed/ K&Rish,
absolutely /no/ spaced indentation, but indent -nut fits zebra -
we're not going to reformat the code completely just for the fun of
it).

> and so on. I believe it's high time we setup those decisions,
> before bulks of code start coming in...

:)

> - even more about patching: IMO, it's truely fundamental for quagga
> to catch up with zebra patches, if and when they occur (since these
> are rather rare occasions, it shouldn't be too difficult).

Yes. We'll keep track of zebra.org. But to be honest, I doubt we'll
see many. (i've merged twice from zebra.org since march, both very
small changes). Would loved to be proven wrong, would love to see
zebra.org suddenly take off in a huge flurry of activity (Kunihiro is
an /excellent/ developer), but i dont see it happening.

> But, besides tracing, this principal (assuming it is agreed upon
> everyone), suggests that quagga should part from zebra as *least*
> as possible, with respect to code structure, naming (files,
> functions, variables, constants, enumerators); furthermore, such
> approach implies that extensions to current code should be done in
> an accumulative fashion, rather that a destructive one. I'm not
> sure this is acceptable on others, is it?

Well, lets see what happens. If someone puts the time and effort in
to redo something in a better way, great - why not accept it? Lets
see what people do - there's no sense in putting restrictions in
place on change to accomodate /potential/ future merges with
zebra.org when all the signs are that zebra.org is dead. (we wouldnt
be here otherwise).

>
> - version control / branching policy? (no clue, no proposal either)

I like branches. I dislike branches in CVS.

I'd like to investigate SVN at some stage, when its settled down a
bit. It seems to handle branching far more intuitatively. And it
would make it possible to give every person who wants to work
regulalry on zebra their own branch, which would be nice.

> To sum up, I truely believe that -- since quagga is a real
> community maintained package (in my mind, at least) -- there needs
> to be some sort of a manifest, easily accessible from the webpage,
> which defines all policies and guidelines with respect to
> development.

well, fire away - i'm open to suggestions :)

>
> Okay, waiting for flames... ;-o
>
> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Have you ever noticed that the people who are always trying to tell you
`there's a time for work and a time for play' never find the time for play?

On Sun, 3 Aug 2003, Ted Mittelstaedt wrote:

> >- even more about patching: IMO, it's truely fundamental for quagga to
> >catch up with zebra patches, if and when they occur (since these are
> >rather rare occasions, it shouldn't be too difficult). But, besides
> >tracing, this principal (assuming it is agreed upon everyone), suggests
> >that quagga should part from zebra as *least* as possible, with respect
> >to code structure, naming (files, functions, variables, constants,
> >enumerators); furthermore, such approach implies that extensions to
> >current code should be done in an accumulative fashion, rather that a
> >destructive one. I'm not sure this is acceptable on others, is it?
> >
>
> It is just going to be tremendous work to try to "sync" to the
> original Zebra. Plus there's 2 other issues:
>
> 1) It dilutes "The Quagga project" control over copyright to continue
> to pull in changes from Zebra
>
> 2) With the zebra.org community gutted by Quagga, it is going to
> remove any source of patches that Kunihiro was getting.
>
> Ted


I tend to agree with Ted here. Quagga was forked from Zebra because we
could not get patches into Zebra. People were frustrated. The code was
suffering. The userbase was suffering. Developers were going away to
work on code where their work was appreciated enough to be
included. Given past history, I seriously doubt that anyone is going to
be submitting any patches to Zebra and even if they do, I doubt that
they'll make it into the codebase. The word will get out and those people
will come over to Quagga.

We need to make a clean and definate break from any and all dependencies
on Zebra. With it having been a year since a Zebra release, that
shouldn't be too hard. Quagga is Zebra spawn but, it is *NOT* Zebra
anymore. As has been pointed out, this is a decision we were forced to
make, many of us NOT wanting to have to go this route but, now that it is
done, it needs to be complete and unfaltering.

--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

On Sun, 3 Aug 2003, Stephan von Krawczynski wrote:

> I see the quagga project highly equivalent to linux kernel. In fact
> you need people that know the various hw platforms quagga runs on.

exactly.

> Kunihiro always spoke about patches not tested on other hw then the
> submitters'. Though I doubt the argument a bit, there is _some_
> truth in it,

there is. the answer is testing. eg what i did with the privsep code,
i kept it seperate for quite a while, begged people to test it :)
eventually someone came along and tested it out on lots of platforms
and sent me the patches needed to make it work.

whats needed is varying 'orbits' of code. the core code, then patches
or trees with code that people can work on and test and have other
people test.

> namely the project needs a diversification (does this word exist?
> I'm no native) into:
>
> 1) platform independant code
> 2) architecture specific "glue code"
>
> throughout all the daemons. This would imply you need people for
> every arch and people for independant parts.
>
> Your thoughts?

Kunihiro was /way/ ahead of you :)

The code is already very well laid out and the platform dependent
parts are already seperated out nicely. Conceptually at least,
zebra^Wquagga is unfortunately rife with #ifdef's.

> Regards,
> Stephan

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Don't get suckered in by the comments -- they can be terribly misleading.
Debug only code.
-- Dave Storer

On Sun, 3 Aug 2003, John Fraizer wrote:

> suffering. The userbase was suffering. Developers were going away to
> work on code where their work was appreciated enough to be
> included.

Which code base, i suspect, often would be ZebOS.

> they'll make it into the codebase. The word will get out and those
> people will come over to Quagga.

We'll see. There will not suddenly be any miracles with quagga
development, but over time, who knows?

> John Fraizer | High-Security Datacenter Services |

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
We are not a loved organization, but we are a respected one.
-- John Fisher

On Sun, 3 Aug 2003, Stephan von Krawczynski wrote:

> I see the quagga project highly equivalent to linux kernel. In fact you need
> people that know the various hw platforms quagga runs on. Kunihiro always spoke
> about patches not tested on other hw then the submitters'. Though I doubt the
> argument a bit, there is _some_ truth in it, namely the project needs a
> diversification (does this word exist? I'm no native) into:
>
> 1) platform independant code
> 2) architecture specific "glue code"
>
> throughout all the daemons. This would imply you need people for every arch and
> people for independant parts.
>
> Your thoughts?

Well, I can test on MIPS, X86 and possibly SPARC. A client of mine is
very interested in building up a nifty testbed and this looks like a good
reason to do it. My testbed has been dismantled over the past few years
to serve other purposes.

--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

Stephan von Krawczynski wrote:

> I see the quagga project highly equivalent to linux kernel. In fact you need
> people that know the various hw platforms quagga runs on. Kunihiro always spoke
> about patches not tested on other hw then the submitters'. Though I doubt the
> argument a bit, there is _some_ truth in it, namely the project needs a
> diversification (does this word exist? I'm no native) into:
>
> 1) platform independant code
> 2) architecture specific "glue code"
>
> throughout all the daemons. This would imply you need people for every arch and
> people for independant parts.
>
> Your thoughts?

Nice thinking, although I believe is hard to employ: assigning
committers (I prefer "reviewers", more democratic IMO) to components is
rather easy; however, assigning responsibilities for architecture,
keeping in mind that such people must actually be reponsible to certify
that every committed change is working with their platform, implies that
(1) these people are do-it-all experts wrt zebra (oops, quagga!), and
(2) they'll have loads of work to do -- they must approve every change
that happens anywhere in the code, namely each and every patch.
Considering the fact that some platforms are quite singular, let alone
some platforms are inconsistent (e.g. you may say Linux, while referring
to some distro patched kernel, while in fact it isn't necessarily the
same on others), this is quite complicated.

What would I suggest? IMO, the majority of patches to quagga won't carry
any platform-dependent properties: most of what we've seen so far deals
with logic/algorithmic tuning, user interface, and *nix-common
characteristics. Furthermore, it seems that platform-dependent patches
would normally happen around (1) zebra-daemon kernel API
(rt_something.c, if_something.c, ...), or (2) the automake / autoconf /
build environment. Hence, I believe that component-oriented reviewers
(and the patch authors themselves) can indicate quite easily whether or
not a patch requires cross-platform testing. AFAICT, in most cases it
shouldn't.

Your call?
Gilad

On Sun, 3 Aug 2003 10:39:25 +0100 (IST)
Paul Jakma <paul@clubi.ie> wrote:


> Kunihiro was /way/ ahead of you :)
>
> The code is already very well laid out and the platform dependent
> parts are already seperated out nicely. Conceptually at least,
> zebra^Wquagga is unfortunately rife with #ifdef's.

And that is exactly what I was referring to ;-)

Regards,
Stephan

On Sun, 3 Aug 2003, Stephan von Krawczynski wrote:

> > parts are already seperated out nicely. Conceptually at least,
> > zebra^Wquagga is unfortunately rife with #ifdef's.

arg, punctuation is misleading above, should read:

"parts are already seperated out nicely, conceptually at least. zebra
is, unfortunately though, rife with #ifdef's"

> And that is exactly what I was referring to ;-)

yes, there's a good bit of cleaning up that can be done.

> Regards,
> Stephan

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Your fault -- core dumped

On Sun, 03 Aug 2003 12:44:00 +0300
Gilad Arnold <gilad.arnold@terayon.com> wrote:

>
> Stephan von Krawczynski wrote:
>
> > [...]
> > 1) platform independant code
> > 2) architecture specific "glue code"
> >
> > throughout all the daemons. This would imply you need people for every arch
> > and people for independant parts.
> >
> > Your thoughts?
>
> Nice thinking, although I believe is hard to employ: assigning
> committers (I prefer "reviewers", more democratic IMO) to components is
> rather easy; however, assigning responsibilities for architecture,
> keeping in mind that such people must actually be reponsible to certify
> that every committed change is working with their platform, implies that
> (1) these people are do-it-all experts wrt zebra (oops, quagga!), and
> (2) they'll have loads of work to do -- they must approve every change
> that happens anywhere in the code, namely each and every patch.
> Considering the fact that some platforms are quite singular, let alone
> some platforms are inconsistent (e.g. you may say Linux, while referring
> to some distro patched kernel, while in fact it isn't necessarily the
> same on others), this is quite complicated.
>
> What would I suggest? IMO, the majority of patches to quagga won't carry
> any platform-dependent properties:

Well, actually they don't because they can't :-)

My idea was (pretty obvious but nevertheless for completeness):

bgpd needs a maintainer who has deep knownledge about bgp
ospfd needs a maintainer who has deep knowledge about ospf
ripd needs - well, you name it ;-)

quaggad needs a maintainer who has deep knowledge about multitasking
application design (uh?)

quaggad-plugin-linux needs a maintainer who has deep knowledge about
interfacing to linux kernel routing code and process/thread stuff.
quaggad-plugin-solaris needs ...

You get the idea?

quaggad is in fact a very abstract piece of code that should have no idea at
all about the hw it runs on. It needs an abstraction layer that allows to use
all platforms equivalently.

Same goes for e.g. bgpd which very likely needs an abstraction layer for
process an timer-interrupt scheduling.
ospfd probably just the same.

So working idea should be top-down. bgpd-maintainer states what functionality
is needed to built a completely conform bgp implementation. Same for all other
routing protocols. Arch maintainer then should be able to cope with that and
implement the features needed.

This is all where basic brainstorming, and completely off-topic in the
users-list :-)

Regards,
Stephan

Stephan von Krawczynski wrote:

...
>>What would I suggest? IMO, the majority of patches to quagga won't carry
>>any platform-dependent properties:
>
>
> Well, actually they don't because they can't :-)
>
> My idea was (pretty obvious but nevertheless for completeness):
>
> bgpd needs a maintainer who has deep knownledge about bgp
> ospfd needs a maintainer who has deep knowledge about ospf
> ripd needs - well, you name it ;-)
...
> You get the idea?

I'm not sure... let me see, you mean that isisd needs a maintainer with
deep knowledge of, hmmm... IS-IS?? Elementary, Watson... (Yes, I get
it, thank you for being so illustrative... ;-> )

> quaggad is in fact a very abstract piece of code that should have no idea at
> all about the hw it runs on. It needs an abstraction layer that allows to use
> all platforms equivalently.

Appears I wasn't very clear: in fact, I meant the OS/kernel (Linux with
different kernel APIs, BSD flavors, Solaris, you name it) and it's
accompanying development environment (libc, gcc, make/gmake, automake),
and not the hardware -- clearly the latter has nothing to do with
zebra/quagga whatsoever. I believe this is what Kunihiro referred to
when he spoke of portability.

> This is all where basic brainstorming, and completely off-topic in the
> users-list :-)

Trivial. (And off-topic ;-> ) (yet, from my humble experience with
zebra patching, this is an issue)

Gilad

Oh yes..

One other thing to consider:

- version numbers.

Its been hard to distinguish CVS snapshots from actual releases (eg
bug reports). I'm going to bump the version number in CVS. When
there's a release, the number will bump again, ie there will be
version numbers which will only ever appear in CVS, release numbers
will only ever be in a release, eg, something like

CVS Release
0.95
-> 0.96
0.97

Ie a release would go like:

- bump version number
- release
- bump version number

you could even make it a rule of thumb that odd numbers are internal,
CVS only, never released versions - even are very specific releases.

or we could just add a minor number. :)

?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The meek shall inherit the earth; the rest of us, the Universe.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Paul Jakma wrote:
|>- version control / branching policy? (no clue, no proposal either)
|
| I like branches. I dislike branches in CVS.
|
| I'd like to investigate SVN at some stage, when its settled down a
| bit. It seems to handle branching far more intuitatively. And it
| would make it possible to give every person who wants to work
| regulalry on zebra their own branch, which would be nice.

I'm long since trying to convince Paul of the usability of Subversion...
... it seems some of my words have grown roots ;-))

Branching and merging would be very painless using SVN. The question of
multiple branches for different points of focus would simply be to do a
'svn cp /trunk /branches/mybranch' and merging back changes would be
very easy, even when having _lots_ of branches...

Those of you already using Subversion for other projects, who are
interested in Quagga/Zebra-pj could take a look at my site
https://zebra.datacore.ch.

The site contains a Subversion repository which is tracking Zebra,
Zebra-pj and my own Zebra-ag branch (please ignore Zebra-ag, it's my own
branch where I do SRRD development in...).

The site hosts a ViewCVS for all three branches and a Subversion
repository with public read-only access to these.

Subversion users which already know the resourcefullness of SVN (and
those who want to try it out) are free to use my repository to do their
Zebra/Quagga development with Subversion.

It's very conventiant to use SVN for this. I do this all the time. When
finished with my changes (committed to my SVN repository), I generate a
diff or I concatenate the commit emails, and send them to Paul to add to
the CVS repository.

If you are interested in SVN access to the sources, you can find access
information for SVN on the following page:

https://zebra.datacore.ch/DCwiki.zebra/Wiki.jsp?page=Repos.Zebra

Regards
- - Amir
- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/LSHgbycOjskSVCwRAqyHAKDSeBMAks4aZID5aZ1St4wipLWfoQCg6ReZ
qA0Awg44xr890k0syFeiY4k=
=kR4o
-----END PGP SIGNATURE-----

On Sun, Aug 03, 2003 at 04:53:20PM +0200, Amir Guindehi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> Paul Jakma wrote:
> |>- version control / branching policy? (no clue, no proposal either)
> |
> | I like branches. I dislike branches in CVS.
> |
> | I'd like to investigate SVN at some stage, when its settled down a
> | bit. It seems to handle branching far more intuitatively. And it
> | would make it possible to give every person who wants to work
> | regulalry on zebra their own branch, which would be nice.
>
> I'm long since trying to convince Paul of the usability of Subversion...
> ... it seems some of my words have grown roots ;-))

If there is going to be a conversation about which RCS to use I would
like to suggest Arch.

Here is a subjective comparision on SubVersion CVS and Arch:

http://arch.fifthvision.net/bin/view/Main/SubVersionAndCvsComparison

I use Arch exclusivly at my day job and have yet to find a branching/merging
problem it couldn't handle.

> Branching and merging would be very painless using SVN. The question of
> multiple branches for different points of focus would simply be to do a
> 'svn cp /trunk /branches/mybranch' and merging back changes would be
> very easy, even when having _lots_ of branches...
>
> Those of you already using Subversion for other projects, who are
> interested in Quagga/Zebra-pj could take a look at my site
> https://zebra.datacore.ch.
>
> The site contains a Subversion repository which is tracking Zebra,
> Zebra-pj and my own Zebra-ag branch (please ignore Zebra-ag, it's my own
> branch where I do SRRD development in...).
>
> The site hosts a ViewCVS for all three branches and a Subversion
> repository with public read-only access to these.

I can expose my Arch archive if people would like to browse it and
compare.

My $0.02 (US)

> Subversion users which already know the resourcefullness of SVN (and
> those who want to try it out) are free to use my repository to do their
> Zebra/Quagga development with Subversion.
>
> It's very conventiant to use SVN for this. I do this all the time. When
> finished with my changes (committed to my SVN repository), I generate a
> diff or I concatenate the commit emails, and send them to Paul to add to
> the CVS repository.
>
> If you are interested in SVN access to the sources, you can find access
> information for SVN on the following page:
>
> https://zebra.datacore.ch/DCwiki.zebra/Wiki.jsp?page=Repos.Zebra
>
> Regards
> - - Amir
> - --
> Amir Guindehi, nospam.amir@datacore.ch
> DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2-nr1 (Windows 2000)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQE/LSHgbycOjskSVCwRAqyHAKDSeBMAks4aZID5aZ1St4wipLWfoQCg6ReZ
> qA0Awg44xr890k0syFeiY4k=
> =kR4o
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users

--
James R. Leu

On Sun, Aug 03, 2003 at 10:39:25AM +0100, Paul Jakma wrote:
<snip>
> Kunihiro was /way/ ahead of you :)
>
> The code is already very well laid out and the platform dependent
> parts are already seperated out nicely. Conceptually at least,
> zebra^Wquagga is unfortunately rife with #ifdef's.

I would like to see a much more formal 'porting-layer'. If you would
like to see an example of what I mean, take a look at my 'ldp-portable'
package. The guts of the package are a library which implement RFC 3036
(Label Distribution Protocol for MPLS). It uses a 'porting-layer' or
well defined API, to interact with the underlying system. In this case I
have implemented a layer to interact with zebra. In the pass I've
implemented layers that interact with the linux kernel, and the freebsd
kernel.

ldp-portable is part of http://mpls-linux.sf.net/

If people are serious about architecting quagga to be more OS independent
I would be happy to start a discussion about it and keep track of
the results of that discussion.


--
James R. Leu

>
> > Regards,
> > Stephan
>
> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Don't get suckered in by the comments -- they can be terribly misleading.
> Debug only code.
> -- Dave Storer
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users