[linux-cifs-client] Re: cp -p localfile to a winnt, w2k0, winxp server - and legacy servers like win98SE and OS/2 - does _not_ succeed. To get that tracked now, i'll open a samba bugzilla entry, too

[Günter Kukkukk]

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.

Cheers, Günter