Subject: Re: [vserver] Roadmap and Future ...
From: Ed W <lists@wildgooses.com>
Date: Sat, 28 Feb 2009 11:56:59 +0000
Sat, 28 Feb 2009 11:56:59 +0000
Herbert Poetzl wrote:
>> "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
>   

Actually I think with these opensource projects it becomes a bit of both.

My own experience is that I often arrive a new project and don't want to
try and contribute anything too large in case it's not heading in the
right direction for the project (no point doing work and having it
discarded).  If there is no obvious direction then I might more easily
give up and go somewhere else.

Having a few signposts and suggestions leads to people to perhaps go
further and pickup a project

For example I think good examples are:

- Your suggestion for a gui/web monitor
- Your writing of this "roadmap" email

Both have garnered some interesting response and hopefully if you guide
some of this effort it will go somewhere?



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

I have never worked with the linux kernel (or other huge project), but
for the smaller projects I use git on I find it excellent that you can
fork away and create loads of little trees of changes and commits, mix
and match them and then only push them up to head when you are happy. 
However, it's a piece of cake to say "try branch new-net-code " and
people can give it a go without it needing to be in mainline

An example of where git (for example) really works is keeping that
branch up to date.  eg for a long while mythtv had some interesting
development forks for more advanced video playback and recording
changes.  However, because it was in a separate SVN tree it was a fair
bit of work to keep that up to date with HEAD in the main repo, so for
most people you either followed HEAD or the fork.  In contrast I have
quite a few git repos where I have made changes and *long term* follow
the HEAD, yet still with the benefit of my local customisations staying
up to day (I also try to do this with Myth SVN and find it a complete
pain in the arse...). 

Also if you use "git rebase" in your private repo then it's smart enough
to actually fold in changes which are accepted upstream into the
outstanding patches being followed locally!  So if half a patch is
accepted and the other bit not, then I am left with a single smaller
sized outstanding patch in my local tree - this is very helpful!


I personally have zero patches to vserver, so can hardly claim this is
currently helpful in this situation, but for those wanting to contribute
code I think the point remains the same.  With some source code control
systems you can have both blow by blow commits (that might not work!!),
yet still have a "stable" mainline at all times.

The Dovecot maintainer is very helpful in this regard.  As people report
bugs you often get back a link to the exact commit which will fix the
issue.  It's clearly very possible to apply only that commit to some
older version of the code and benefit from the bug fix.  Again, not
claiming this is even needed here, but it's nice to have and comes for
free from more modern DVCS systems.

Good luck

Ed W


P.S.  Can people please trim their replies - it's getting hard to read
some of the very long replies


Herbert Poetzl wrote:
"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
  

Actually I think with these opensource projects it becomes a bit of both.

My own experience is that I often arrive a new project and don't want to try and contribute anything too large in case it's not heading in the right direction for the project (no point doing work and having it discarded).  If there is no obvious direction then I might more easily give up and go somewhere else.

Having a few signposts and suggestions leads to people to perhaps go further and pickup a project

For example I think good examples are:

- Your suggestion for a gui/web monitor
- Your writing of this "roadmap" email

Both have garnered some interesting response and hopefully if you guide some of this effort it will go somewhere?



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
  

I have never worked with the linux kernel (or other huge project), but for the smaller projects I use git on I find it excellent that you can fork away and create loads of little trees of changes and commits, mix and match them and then only push them up to head when you are happy.  However, it's a piece of cake to say "try branch new-net-code " and people can give it a go without it needing to be in mainline

An example of where git (for example) really works is keeping that branch up to date.  eg for a long while mythtv had some interesting development forks for more advanced video playback and recording changes.  However, because it was in a separate SVN tree it was a fair bit of work to keep that up to date with HEAD in the main repo, so for most people you either followed HEAD or the fork.  In contrast I have quite a few git repos where I have made changes and *long term* follow the HEAD, yet still with the benefit of my local customisations staying up to day (I also try to do this with Myth SVN and find it a complete pain in the arse...). 

Also if you use "git rebase" in your private repo then it's smart enough to actually fold in changes which are accepted upstream into the outstanding patches being followed locally!  So if half a patch is accepted and the other bit not, then I am left with a single smaller sized outstanding patch in my local tree - this is very helpful!


I personally have zero patches to vserver, so can hardly claim this is currently helpful in this situation, but for those wanting to contribute code I think the point remains the same.  With some source code control systems you can have both blow by blow commits (that might not work!!), yet still have a "stable" mainline at all times.

The Dovecot maintainer is very helpful in this regard.  As people report bugs you often get back a link to the exact commit which will fix the issue.  It's clearly very possible to apply only that commit to some older version of the code and benefit from the bug fix.  Again, not claiming this is even needed here, but it's nice to have and comes for free from more modern DVCS systems.

Good luck

Ed W


P.S.  Can people please trim their replies - it's getting hard to read some of the very long replies