Subject: Re: [vserver] Roadmap and Future ...
From: Ed W <lists@wildgooses.com>
Date: Thu, 26 Feb 2009 20:07:55 +0000
Thu, 26 Feb 2009 20:07:55 +0000
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 :)
>   

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

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
>   

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.

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
>   

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...

I believe there are some git servers that someon 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.

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?

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 luck

Ed W



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 :)
  

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

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
  

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.

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
  

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...

I believe there are some git servers that someon 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.

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?

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 luck

Ed W