On Thu, 2009-02-26 at 20:07 +0000, 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 :) > > > > 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 I believe Ed is giving some excellent guidance here. We are very impressed with the technology of the VServer project but it does not project a very professional ethos, sometimes comes across as a tad bit arrogant, and it's very hard to pick up the project from scratch. All of that can be a sign of overload on a small core of developers so I quite understand. On the other hand, I have found the developers unbelievably supportive - I can't say enough good in that area. However, appearance and ease of entry are important to attract new users and contributors. If it were not for the outstanding technology, I certainly would have gone elsewhere and never known about the great support. We are planning to build a large part of our new business on VServer and would be very happy to contribute as soon as we build our revenue stream. This is far too great a project to let die! Thanks for all you've done, all you VServites! -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society