Subject: Re: [vserver] Roadmap and Future ...
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 27 Feb 2009 01:16:59 +0100

On Thu, Feb 26, 2009 at 03:28:48PM -0600, Michael S. Zick wrote:
> 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!

point taken,
will try to work something out

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

it was once the main site for 'my' contributions to
Linux-VServer (before I accepted maintainership and
before we had linux-vserver.org ...

so granted, I neglected _my_ pages to spend a little
more time on a community project I'm maintaining :)

but you are probably right there too, that I should
focus a little more on PR (on all ends), as nobody
seems to be willing to step up and do the PR stuff
(and we definitely need that)

still it is very sad that the main kernel developer
has to do that part too ....

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

I'm not sure that I want to be a 'leader' ...
I think the 'maintainer' part suits me more, but we'll see ...

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

very similar to commits to a git repository, no?

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

nah, when we fix something, or test a new feature,
there are patches (again, equivalents to commits)
which are uploaded instantly, so far from a product
or release

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

that will lead to a lot of broken, non compiling
kernels out there and many many unhappy people

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

well, contrary to some/other projects, I do not commit 
something which doesn't even compile or had some basic
testing, so that's the smallest (IMHO sensible) unit
such changes will ever happen, and that is exactly the
amount of diffs or deltas uploaded

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

I disagree here, personally I do not see any gain in
having a repository with a version known to fail,
but maybe you can explain the advantage of that over
'known working' commits?

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

till now, there haven't been any outside the core
development team, but we'll see ...

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

the point which is easily missed here is that:

I do not want to sell a product here, I want to
make high quality software everybody can use in
a free (as in beer and speach) way

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

certainly, but not for washing whiter than white
(as most companies will make you believe :)

> Good wishes here, also.

thanks for the input,
Herbert

> Mike
> 
> > Good luck
> > 
> > Ed W
> > 
> > 
>