Subject: Re: [vserver] Roadmap and Future ...
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sat, 28 Feb 2009 10:01:42 +0100

On Thu, Feb 26, 2009 at 10:30:42PM -0600, Michael S. Zick wrote:
> On Thu February 26 2009, Herbert Poetzl wrote:
>> 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 ...

> So appoint someone.

> "Delegation" is part of leadership also.
> A person, any person, is in a no-win situation until they learn
> to delegate.  The world is too big.

I think I can manage to 'delegate' things, the difference
here (as this is a community and open source project) 
just is that somebody needs to volunteer and to some
degree commit him/herself to the job first

> Of course, this isn't a crew of code-for-hire workers, 
> where you can just point at someone and say: 
> "Your in charge or pick up your last paycheck" - - 
> Kind of hard to do that when there aren't any paychecks. ;)

> But the terms: "Appoint" and "Delegate" do apply - 
> just the method of getting them done in this environment 
> is different.

> Edit your site home page to say (in friendly terms):

> I, Herbert, am the lead maintainer; 
> I write the code, I decide when to tag a release;
> This list of other people are in charge of doing:
> . . .
> so don't even think of bothering me about those details.

similar like http://linux-vserver.org/Developers ?

> That list of "being in charge" of something may be the only
> recognition a volunteer ever gets.  You have to offer at
> least that much incentive.

will try to figure something out for that too :)

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

> Only the people who pull something other than a point marked as
> a "release tag".

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

> Sensible for the delieverable product and counter productive
> to the co-developers of a product.

> Now if you choose to use a source control system that only allows
> a single time check out of a file, meaning only one person can
> make a change in a file at a time because the system locks anything
> checked out to another person . . . then the usage model would be
> different.

> But that is generally true; if things where different, they 
> would not be the same.

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

> TAG the repository at the points where until now you released
> 'known to work' tar-balls.  The tagged point is your "known to work"
> point - perhaps with some sort of qualification (untested, works for
> me, sort-of tested, etc, etc).

> Everything in between tags is understood to NOT BE a 'known to work'
> point in the development.

> The way it is now, no one who clones the repository can tell which
> file you might be working on or have already changed.

> Keeping the repository as current as possible is the only way to
> deal with a situation where files are changed other than by assignment.

okay, I see your point, but why would we want to be
more into extreme development than mainline?

I mean, don't get me wrong here, but if you look at
mainline commits, they are basically always small but
complete patches/patch-sets which are expected to work
(of course, they are often messed up, so they need a
minor fix later, or get reverted till more testing was
done or whatever), but I've never seen a commit for
every line or one which knowingly breaks the kernel

I somehow think that which is good enough for mainline
kernel development, should work for our kernel too

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

> Until now there hasn't been any reference to what/how it should be
> used.  Just this and the prior ML mention of the URL.

correct, becaus it isn't used/needed/wanted by the main
developers (yet)

best,
Herbert

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