From: Blaisorblade <blaisorblade_spam@yahoo.it>
To: "Gerd Knorr" <kraxel@bytesex.org>,
"Steve Schmidtke" <steve_schmidtke@hotmail.com>,
"Felix Müri" <uml@uxu.ch>,
"Michael Richardson" <mcr@marajade.sandelman.ottawa.on.ca>
Cc: Jeff Dike <jdike@addtoit.com>,
user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] What to do with uml_switch?
Date: Sat, 4 Dec 2004 04:52:32 +0100 [thread overview]
Message-ID: <200412040452.32722.blaisorblade_spam@yahoo.it> (raw)
It is apparent that something is wrong with uml_switch (though I don't know
the code and I'm not going to express technical opinion, only "management"
one).
I've just seen about a dozen patches to Steve Schmidtke, two different
rewrites from Gerd and Felix, and a request from Michael to merge some code
(uml_netjig) from OpenSWAN/FreeSWAN (IIRC) into it; and it could be something
very interesting for SuSE customers, I think - I only know that Open/FreeSWAN
it's about VPN, nothing more - so maybe Gerd could be interested in this.
Michael, could you start posting it here, instead that to Jeff (maybe you did
and I didn't notice, if it was time ago, but now it's the moment to repost
it).
Felix, even if your newer code is not yet "releasable", it can help anyway...
even just describing the changes you did and why... design ideas are more
important than code itself sometimes.
Steve, merging at least the earlier of your patches (they are splitup The
Right Way(tm)) might be done soon, without lots of discussions.
If you feel so, you might split uml_switch from the rest (but remember the
user point of view - two packages doubles the setup time).
Anyway rename the uml_router folder to uml_switch, please... time to fix it!
Clearly, Jeff is current working on completely different things, and it's a
right thing for him to do - he is not the "I'll do everything about UML" boy,
and time is short.
It is not even the "UML dictator". So I asked him if someone else could take
over the maintainance of uml_switch, and he basically agreed.
The only doubt is:
1) he wants to appoint somebody he really trusts as the uml_switch maintainer.
2) I think that, within the UML community, there are enough experienced
developers that can work together and get it right themselves, even deciding
for a CVS development model, even because userspace code has different
stability requirements from kernelspace one (not that uml_switch can be
faulty, just it's easier to make it correct than with UML).
This, in the most abstract form, is a well-known debate - think to "The
Cathedral and The Bazaar" by Eric S. Raymond.
I was simply astonished when I read "Think to users as co-developers". I've
never been against that, but reading it so clearly explained made me think.
Now, I've not started distributing SKAS patches because someone told me to do
that. Ingo Molnar was working on it on incompatible ways, so I took his work
and made it backwards compatible, did some other cleanups and published it
all over. Then it become more and more serious... and one week ago Jeff said
"I've just been happy with you taking over the maintainership over it".
If you are good guys (and you are), I think you can sort out by discussing it
here (I'm just against the creation of a separate ML for that development -
things don't work that way).
So, the ball is over to you. In this moment, Gerd Knorr seems the one who has
the time and the position (working in SuSE) to manage it well (he can push
updates to its users and so on, for instance) but it's just my little 2
cents.
Or you might use our wiki (http://uml.harlowhill.com/) as distribution
center... how much of you didn't ever know it exists? Well, it being so
unknown is the biggest bug we experience now.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next reply other threads:[~2004-12-04 3:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 3:52 Blaisorblade [this message]
2004-12-05 3:42 ` [uml-devel] Re: What to do with uml_switch? Michael Richardson
2004-12-06 19:25 ` Gerd Knorr
2004-12-07 16:21 ` Steve Schmidtke
2004-12-08 16:51 ` Michael Richardson
2004-12-08 19:33 ` Gerd Knorr
2004-12-09 3:22 ` Michael Richardson
2004-12-08 19:36 ` Steve Schmidtke
2004-12-08 21:37 ` Michael Richardson
2004-12-09 0:28 ` Steve Schmidtke
2004-12-09 0:53 ` Michael Richardson
2004-12-05 20:00 ` [uml-devel] " Steve Schmidtke
2004-12-06 18:30 ` [uml-devel] " Gerd Knorr
2004-12-06 19:35 ` [uml-devel] " Blaisorblade
2004-12-08 20:24 ` [uml-devel] " Felix Müri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200412040452.32722.blaisorblade_spam@yahoo.it \
--to=blaisorblade_spam@yahoo.it \
--cc=jdike@addtoit.com \
--cc=kraxel@bytesex.org \
--cc=mcr@marajade.sandelman.ottawa.on.ca \
--cc=steve_schmidtke@hotmail.com \
--cc=uml@uxu.ch \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox