Subject: Re: [vserver] Roadmap and Future ...
From: "Michael S. Zick" <mszick@morethan.org>
Date: Thu, 26 Feb 2009 15:28:48 -0600

On Thu February 26 2009, Ed W wrote:
> Herbert Poetzl wrote:
> 
> 
> >> Please think about what you can "sell" me that I can put down on
> >> my books and capitalise in some way as "goodwill" or "research" or
> >> whatever. 
> >>     
> >
> > well, a service contract for, let's say 50 EUR per
> > month would fit your case perfectly fine, and as
> > Linux-VServer user, the books are fine too, if you
> > 'buy' the 'guarantee' that if something goes wrong,
> > one of the specialists will be available to look
> > into it
> >   
> 
> If you can come up with some defined levels from 50EU/month then I think
> you are in good shape.  Some may contribute much more in excess of that,
> but I was concerned that your starting point was much higher and I think
> this is hard for many folks to hit. 
> 
> Dunno though - I guess have a look at the price of Suse/Redhat, etc
> support contracts and work from there?
> 
> 
> >> Also I think this is a good time for vserver to come out and 
> >> start to look like a really professional project. 
> >>     
> >
> > well, given that I can spend some more time on
> > Linux-VServer in general, that probably can be
> > arranged, although I would like to see folks which
> > are doing that for a living to join in instead of
> > the kernel developer(s) designing web pages :)
> >   
> 

Ah, but that is the point that seems to get lost in translation. ;)
Leadership must come from somewhere.

It takes a lot more than just throwing up a blank wiki page and
saying: "Here, fill in what you think is missing".

Even a simple sort of leadership - like post the "Table of Contents"
with 100% of the links leading to a blank page.
You have to at least give people an idea of what you want there.

Of course, "Leadership by Example" is what I beleive works best
in an open community setting, but at least outline the durn site!

> I agree - but I do think this is a really key think to work on if you
> are going to get this thing to snowball.  The website really does
> communicate your project and presence these days.  Sure you had me
> hooked on the feature list, but not everyone buys on features
> 
> Remember you are effectively "competing" for users attention now and
> trying to attract traffic to your site. I think this starts with a
> pretty front page on the website
> 

You even once had a start on that - not maintained for several years now:
http://www.13thfloor.at/vserver/project/

And you find yourself explaining to people who use google that:
"the project is not dead".
Duh. . . Either use it or re-direct it . . . Don't leave it sit there.

> However, Mythtv and other projects I have followed that have "smartened
> up" have done this through help from the community.  I think you need to
> promote a "we need a new website" drive and see if someone on the list
> can't help..?  (Any offers?!)
> 
> 
> >> * Documentation path for the newer users to get started.  
> >>   Which is to say there are some REALLY great docs on the wiki, 
> >>   but they aren't always joined together in a nice path to 
> >>   lead the user down the getting started  process.  
> >>   Again, this hopefully is a volunteer project?
> >>     
> >
> > of course, volunteers to clean up the wiki(s) are
> > always welcome
> >   
> 

At least load FreeTags and start tagging keywords.

> I think you are missing the point that as the project leader you should
> consider trying to become a little more active in directing the
> community and getting this done?  I don't mean that you have to write
> all this stuff, but I do believe that you can "advertise" for people to
> work on stuff and try to direct the efforts of those who do contribute.
> 

What I am trying to communicate - a leader has to provide visible leadership;
which should not translate into: "Write it himself".
Just outlining what you would like to have is only one example.

> Sure people mainly contribute by scratching their itch, but if you can
> give people a few good ideas or give them a bunch of guidance on what
> needs doing then sometimes it helps get things done?
> 
> >> - List of sub projects on the go and their progress. 
> >>   (Some ability to vote on their priority would be nice also)
> >>     
> >
> > if somebody sets something up to do that, I'll
> > gladly fill it with information
> >   
> 
> I meant that it's something that *you* maintain as you work on stuff
> 
> eg you could simply use the summary page on the wiki.  Link this into a
> page for each feature and people can use the talk pages or mailing list
> to discuss further.  I think there are some plugins for media wiki to do
> the usual %complete kind of graphs, etc?
> 
> 
> 
> > I always hear how much Linux-VServer would benefit
> > from a public git/svn/hg repository, but the fact
> > that we have such repositories and nobody wants to
> > actually maintain them is a good indication that
> > something is wrong with that thought
> >   
> 

Here we once again lose something in translation - 
You are doing the work in a "private, I have used it for 7 years"
repository and just pushing complete sets of what you want "public"
into the "public" repository.

Used that way, it is no different than just releasing a patchset.

By "public repository" I mean install a keylogger and push every
keystroke you make, after each press of "enter".

Well, not quite, but a "public, live-as-of-last file save, repository";
not just as-of-last-released patch (that is what "tags" are for).

Of course that means there may be files committed today that you decide
you don't like tomorrow - but that is just human.
Users of "live, public, repositories" are used to that (they make the
same sort of changes-of-mind).

> Actually I really think this is a chicken and egg situation.  If you
> don't have one then people have a barrier to entry and that in itself
> stops people using it...
> 

It will also stop people for paying for getting work done, if they don't
see those half-zillion commits a day. ;)

Of course the head of a live repository will not work, or probably even
compile - but the point is, no one will post changes to a file that you
may have changed last month but not yet "published".

Nothing kills off contribution like "fixed in next release".
Go live with the repository and you avoid that, you also lessen the
effort to merge submissions when you do get them.

> I believe there are some git servers that some one setup, but consider 
> that *I* don't even know how to find your "Experimental patches"
> directory without searching back through this mailing list every time
> and you can see what the benchmark is for someone who *does* actually
> care!  If I have to search the mailing list every time just to find this
> git repo then I'm going to assume that no one cares about it and not use
> that either...
> 
> I really don't know if git is the right answer because I haven't worked
> on a project which is basically a bunch of changes against another
> project, but making it simple to contribute is the main goal.  My
> problem with patches is that it's not so easy to see what changes
> between each patch?
> 
> Also, I have no idea how to get started with vserver code.  However,
> when the git link was posted some weeks back I did spend some time
> clicking around through the code because it was suddenly quite possible
> to click around and get an idea on how the patches modify the code, ie
> the 20,000 feet view.  I found it very helpful actually.
> 
> Also on any new project I grab I tend to now browse the commits on
> interesting files - I personally find that the individual changes help
> figure out how the code works
> 
> 
> Seriously though - this is not about intellectual masterbation of having
> a git repo - pick something which works!  However, I think that the
> number of people saying that you need something highlights that people
> currently don't "get" the the current process.  Please "do" something
> even if it's only to add further documentation on why patches are the
> bees knees...
> 
> Since nearly everyone else in kernel world now uses git I do think it
> might be worth evaluating the cost of moving your process and whether it
> doesn't gain anything if at least stopping people winging?
> 
> 
> > the problem is, mainline is not interested ...
> > we did a major code cleanup, which made some code
> > parts less readable for the developers, to completely
> > comply with mainline coding style about two years
> > ago, but mainline keeps reimplementing Linux-VServer
> > code (which seems to be the only way to get parts of
> > it mainlined atm)
> >   
> 
> This is still the chicken and egg situation.  If you don't care about
> them then they have no reason to care about you. 
> 
> I see no reason that all of vserver needs to be merged, but I do think
> it should be a stated goal to be *trying* to merge stuff upstream (where
> it makes sense).  Building bridges with the small stuff is where it starts..
> 
> 
> > save processes (and in the future entire guests)
> > to disk (while they are running) and resume that
> > state at any time in the future, on a reasonably
> > similar hardware ...
> >   
> 
> Hmm, sounds great.  Personally don't have a need for that though.  (sure
> others do though - just my needs are simple)
> 
> Personally would like to see more well documented tools for doing stuff
> like bouncing the vserver, snapping it with lvm, restarting, etc. 
> Syncing safely across between servers.  Backing up vservers using
> rsync/s3/etc without messing up links (current docs are a bit
> confusing).  Getting unification working smoothly (at least for me on
> gentoo it needs tweaking to the scripts and I just ran out of time
> trying to figure out what to change)
> 
> 
> >>> I also plan to do a web frontend to control basic
> >>> functionality and a minimalistic host distribution
> >>> to run Linux-VServer Guests on, but I have no idea 
> >>> when I will find time for that.
> >>>       
> 
> Seriously just sketch out the idea for this and then challenge someone
> on the Rails/Merb/Camping/Php list to write it.
> 

Did I mention: "Leadership desired" yet in this e-mail?

> I think it needs some serious thought first on where the webserver is
> going to live and how the communication will work if we assume separate
> machines?  ssh, daemon with net access?
> 

We are doing that as we type, one list member already heard from:
Dallas Kashuba <dallas@dreamhost.com>

Not only do they provide hosting, they are listed in your Wiki, they
are using VServer commercially, and they have (or recently had) some
public specials on people willing to move to the new L-VS clusters.

> Personally I don't want much in the host, and certainly not a webserver
> or anything too heavy.  Could probably allow Perl and a few POE modules,
> but would be reluctant even for the amount of junk that this pulls in...
> 
> Perhaps have a look at "God" and "monit" for some ideas?
> 
> 
> 
> >> Only get something out which is "stable" in the sense 
> >> that you call it that!
> >>     
> >
> > well, usually Linux-VServer development or even
> > experimental releases are as least as stable as
> > the stable mainline kernel releases, but yeah,
> > we definitely want to get a feature complete and
> > well tested 'stable' release out
> >   
> 
> Yeah, but again at the risk of being too pointed.  I still think that
> you aren't realising that you are cutting off a good chunk of your
> potential "market" because you are mis selling the product.  There is an
> expectation of release cycles and things being called betas and some
> stability of the stuff which is a release, etc.  Those who are close to
> the problem realise that it's all smoke and mirrors and labelling game,
> but humans like consistency, so do what the other guys do and label the
> thing differently!
> 
> Seriously - change the website to say:
> 
> "It's stable - version 1 of vserver released.  It slices,dices and
> washes whiter than white"
> 
> Chuck and article on slashdot and watch half the world beat a path to
> your door.  
> 
> Market the product more! Vserver is a great project and deserves more
> exposure!
> 

Good wishes here, also.
Mike

> Good luck
> 
> Ed W
> 
>