[linux-cifs-client] linux-cifs workflow and git trees (was: cp -p localfile to a winnt, w2k0, winxp server - and legacy servers)

[Jeff Layton]

On Sat, 2 Aug 2008 07:50:23 +0200
Günter Kukkukk <linux at kukkukk.com> wrote:

> Am Dienstag, 29. Juli 2008 schrieb Jeff Layton:
> > On Fri, 25 Jul 2008 11:34:57 +0530
> > Suresh Jayaraman <sjayaraman at suse.de> wrote:
> > 
> > > Steve French wrote:
> > > > Starting to catchup now.   I like the idea of having a devel branch
> > > > that anyone could push to but not sure the easiest way to handle this.
> > > 
> > > 
> > > Yeah, I think it is a good idea to have a devel branch. I can think of 
> > > two approaches which might be suitable.
> > > 
> > > 1. We could have a shared central repository where multiple developers 
> > > can push changes (via SSH) to devel branch. But those primary developers 
> > > will need to have SSH access. An sample workflow:
> > > 
> > > - Developer clones the repo and setup a local working branch
> > > - Developer makes changes and tests, gets it reviewed, sign-off
> > > - Developer prepares a branch to push
> > >      * switches to that branch
> > >      * git format patch (redirect as a file)
> > >      * git applymbox
> > > - Developer pushes changes via SSH to the devel branch (Rebase if required)
> > > - Delete the branch which was pushed, once we're done with it
> > > 
> > > Note: we need to make sure we are pushing only the prepared branch and 
> > > not master (explicitly specify the local and the remote branch)
> > > 
> > > 2. Alternatively, as Jeff hinted, developers can have their own public 
> > > hosted trees and once the feature/work is completed/tested/reviwed 
> > > developers can request for a pull. The responsibility of keeping their 
> > > tree up-to-date with the Maintainer's tree lies with the developers.
> > > 
> > > Thoughts? Comments?
> > > 
> > > 
> > > Thanks,
> > > 
> > 
> > My preference would be for #2 here. I'm working on getting a public
> > git tree, but it may be a bit before I get it going. It'll probably
> > also take me a bit to get the workflow down correctly, etc.
> > 
> > Either way though, it's clear that we need to change our development
> > model some. The 2.6.27 merge window just closed, and very few of the
> > patches that were queued up before it opened have been merged.
> > 
> > It's not really possible to get these patches reviewed and merged into
> > Steve's tree and then get them pushed to mainline in the short merge
> > window. Ideally, we'd have them all in a branch ready to be pulled into
> > mainline when the merge window opens.
> > 
> > Having a devel branch would also expand testing of these patches, and
> > give us good way to get them into linux-next.
> > 
> 
> to my best knowledge, there are only a few developers (3...5 ?), which 
> _actively_ work on improvements of the cifs code.
> 
> Anyway - in all cases Steve decides, which patches should went
> upstream - or not.
> 
> So all the burden to deliver a working quality kernel module
> is focussed on Steve's "overall knowledge about ongoing change
> requests - or even radical changes to the code base at all".
> 
> Ouch - not an easy task!
> 
> I think, _one_ new additional public cifs git tree for developers
> should be enough - probably combined with some really needed talks 
> on IRC - to coordinate "all the change requests" ...
> 
> I really would prefer irc channel #samba-technical - but a
> separate channel #cifs-technical could also be a choice.
> 


I also don't envy Steve's task, which is why I'd like to see us use the
tools to make it easier for him...

My idea about having my own git tree is really just as an
organizational tool to make it easier for me to feed patches to him. I
tend to push quite a few patches to Steve and keeping them organized in
email is tough. If I were to host a "for-cifs-devel" branch on my git
tree that has patches that I'm ready to push to Steve then that makes
it easier for him to pull them into his tree. For people who post
patches only occasionally, it's probably not as useful and the list is
fine.

I don't think anyone else but Steve would be a "consumer" of my tree.
What would be nice though is an extra devel or test branch in Steve's
tree for active development. Steve could pull new patches into that
branch without fear of breaking the "main" branch that he feeds to
Linus. As patches mature in that branch they could then be moved to a
"for-linux-next" branch and then eventually a "for-linus" branch...

The details of this are really up to him, but I do think that we need
some mechanism to keep patches from just sitting on the mailing list.
Right now, they're just not getting the testing exposure that they
should...

Coordination via IRC would also be a good thing. #samba-technical works
for me too. We can always open a new channel if that becomes too messy.

-- 
Jeff Layton <jlayton at redhat.com>