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