> > > also, if the upstream
> > > changes touch code that conflicts with a backport
> > > patch, you get to fix the problem as it happens
> >
> > That's exactly the thing that I do not want to do.
>
> you don't want to know about a problem a patch
> until days or weeks later when the auto build
>
hi michael, ...
On Wed, Jul 25, 2007 at 10:27:23AM +0300, Michael S. Tsirkin wrote:
> > > - A single git reset ORIG_HEAD recovers from a conflicting merge
> >
> > handling conflicts is a big part of a maintainer's job!
>
> Because you are a driver maintainer.
> That's what's different here from
> > - A single git reset ORIG_HEAD recovers from a conflicting merge
>
> handling conflicts is a big part of a maintainer's job!
Because you are a driver maintainer.
That's what's different here from regular merge.
Please understand: we have upstream code and we have changes against it.
Upstream
hi michael, ...
On Tue, Jul 24, 2007 at 08:52:20PM +0300, Michael S. Tsirkin wrote:
> > i'd _really_ like to see a list of the advantages of
> > patches over branches. it's hard for me to know if
> > i'm just missing something if the case is not laid out...
thanks for the list...
> Here's a sho
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Here's a short list off the top of my head
> >
> >- A single git pull merges any number of backport changes
> >- A single git reset ORIG_HEAD recovers from a conflicting merge
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >But the proposal here was to have a bush of branches, all of which
> >need to be merged at the same time. It's possible that some
> >would merge and some would fail, leaving m
Here's a short list off the top of my head
- A single git pull merges any number of backport changes
- A single git reset ORIG_HEAD recovers from a conflicting merge
- A single tag tags all code for all kernels
- On update from upstream, if there is a conflict
between upstream code and and a pa
But the proposal here was to have a bush of branches, all of which
need to be merged at the same time. It's possible that some
would merge and some would fail, leaving me in an inconsistent state,
and no easy way to get back to where I started.
A fix could be applied to some kernels, but not oth
> i'd _really_ like to see a list of the advantages of
> patches over branches. it's hard for me to know if
> i'm just missing something if the case is not laid out...
Here's a short list off the top of my head
- A single git pull merges any number of backport changes
- A single git reset ORIG_H
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Examples: What if there's a conflict? I currently do git reset, we'll
>
> If there's a conflict applying a patch, you reject it. I fail to see any
> issue
> here.
But the
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >Hmm. Concider that yuou did all of the above, and then mail me
> >that there's an update. Now I need to merge updates to multiple branches
> >directly
> >and git pull does no
hi michael, ...
On Tue, Jul 24, 2007 at 08:19:24PM +0300, Michael S. Tsirkin wrote:
> > i realize that you're attached to your current method,
> > but i've _used_ a different method, and i can say from
> > experience that it works _much_ better...
>
> I'd like to see a clean method, that doesn't
>Examples: What if there's a conflict? I currently do git reset, we'll
If there's a conflict applying a patch, you reject it. I fail to see any issue
here.
- Sean
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailm
> i realize that you're attached to your current method,
> but i've _used_ a different method, and i can say from
> experience that it works _much_ better...
I'd like to see a clean method, that doesn't replace one set of
problems that I understand with another that I have to learn.
> at sonoma,
> one of the goals of OFED 1.3 is to make access
> to the source easier. to do that, we will prob
> need to rid ourselves of patches...
I'm working on a rather simpler solution to this problem.
Stay tuned.
--
MST
___
ewg mailing list
ewg@lists.openfab
Hmm. Concider that yuou did all of the above, and then mail me
that there's an update. Now I need to merge updates to multiple branches
directly
and git pull does not do this. It's a problem.
A simple script can do this.
You'll have to check out branches one by one, and do a pull.
What if the
hi michael, ...
On Tue, Jul 24, 2007 at 07:52:03PM +0300, Michael S. Tsirkin wrote:
> [...]
> > i have found that drawing a DAG with graphviz has
> > been a big help in making sure that i organize the
> > branches correctly...
>
> Ugh .. *that* sounds complicated.
> Looks like it's much simpler w
hi michael, ...
On Tue, Jul 24, 2007 at 07:55:50PM +0300, Michael S. Tsirkin wrote:
> [...]
> > what is it about patches that are less evil
> > than changesets? can you list some of the
> > advantages?
>
> changesets *do not exist* in git - git tracks content.
>
> I compare "multiple directorie
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 07:16:46PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > But, for these cases where the code actually needs to be modified,
> >
> > Because you only have your driver to maintain.
>
> no, i have to maintain quite a few of the
> ofed backport branches as well for our release.
> if i started getting pull requests from people
> with changes to 15 backport branches in one go,
> i'd probably want to script it...
Yea. Happens al
hi michael, ...
On Tue, Jul 24, 2007 at 07:16:46PM +0300, Michael S. Tsirkin wrote:
> [...]
> But, for these cases where the code actually needs to be modified,
> applying a patch seems like the least evil way to do it.
> Alternatives seem to be much worse.
what is it about patches that are less
hi michael, ...
On Tue, Jul 24, 2007 at 07:23:06PM +0300, Michael S. Tsirkin wrote:
> [...]
> > for just the backport branches, i merge different ways
> > from different sources:
> >* from upstream, it's a pull into master and a git merge master
> > into local backport branches -- i call
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:53:48PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > > well, no, i _have_ been doing development on the
> > > local branches
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> >at qlogic we now keep the backports as branches in
> >our git tree and this, i find, is much easier to
> >handle. because:
> >
> >* viewing and navigating backport source bec
hi michael, ...
On Tue, Jul 24, 2007 at 06:53:48PM +0300, Michael S. Tsirkin wrote:
> [...]
> > well, no, i _have_ been doing development on the
> > local branches in our internal repo. i also
> > merge in changes that you make to the ofed repo
> > to our internal backport branches. the script
>
>at qlogic we now keep the backports as branches in
>our git tree and this, i find, is much easier to
>handle. because:
>
>* viewing and navigating backport source becomes
> _much_ easier.
>* merges are easier -- patches are much more fragile
> than branches.
>* comparisons are easier -- checkin
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:09:09PM +0300, Michael S. Tsirkin wrote:
> > > Quoting Arthur Jones <[EMAIL PROTECTED]>:
> > > Subject: Re: [ofa-general] ANNO
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:32:28PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > > > For example, git pull can only merge one branch at a time.
> > >
>
hi michael, ...
On Tue, Jul 24, 2007 at 06:32:28PM +0300, Michael S. Tsirkin wrote:
> [...]
> > > For example, git pull can only merge one branch at a time.
> >
> > how is this a problem? the way i use git,
> > i use a script to "reflow" the changes into
> > the dependent branches. over the las
hi michael, ...
On Tue, Jul 24, 2007 at 06:09:09PM +0300, Michael S. Tsirkin wrote:
> > Quoting Arthur Jones <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
> >
> > hi michael, ...
> >
> > On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsi
> Quoting Arthur Jones <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
> hi michael, ...
>
> On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote:
> > [...]
> > But I also see a serious problem with addressing: basically
> > git tra
hi michael, ...
On Tue, Jul 24, 2007 at 06:03:41AM +0300, Michael S. Tsirkin wrote:
> [...]
> But I also see a serious problem with addressing: basically
> git tracks content. It's not designed to track a bush
> of branches taken together. For example, take tagging:
> tag namespace is global, so
>Quoting Arthur Jones <[EMAIL PROTECTED]>:
>Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
>hi michael, ...
>
>On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
>> For whom it may concern,
>> I have created an ofed git tree updated with kernel bits fro
hi michael, ...
On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
> For whom it may concern,
> I have created an ofed git tree updated with kernel bits from 2.6.22-rc4,
> and put that up at git://git.openfabrics.org/~mst/ofed_kernel.git
> [...]
> In particular, there were a ton
Erez Zilber wrote:
>> Erez, and other iser maintainers, I had a problem with RHEL4 iscsi backports
>> (scsi_flush_work isn't exported) I decided that since it isn't
>> called on older kernels it's reasonably safe to just comment it out,
>> but would be interested to hear you opinion.
>> See it in t
> Erez, and other iser maintainers, I had a problem with RHEL4 iscsi backports
> (scsi_flush_work isn't exported) I decided that since it isn't
> called on older kernels it's reasonably safe to just comment it out,
> but would be interested to hear you opinion.
> See it in this sub-directory:
> ke
hi michael, ...
On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
> [...]
> In particular, there were a ton of ipath patches that it seems were
> for the most part applied.
> Qlogic maintainers, please help double check that I did not miss something
> of value.
we've amassed a b
37 matches
Mail list logo
