MIPS NPTL patches [1/3]

[Dan E]

On Thu, 09 Apr 2009 04:33 -0400, "Mike Frysinger" <vapier at gentoo.org>
wrote:
> On Thursday 09 April 2009 04:01:23 Dan E wrote:
> > On Thu, 09 Apr 2009 02:54 -0400, "Mike Frysinger" wrote:
> > > On Wednesday 08 April 2009 23:44:07 Dan E wrote:
> > > > ---------- patch start ----------
> > >
> > > posting patches inline meant for direct inclusion really only works when:
> > >  - it's only 1 patch
> > >  - patch is at the end of the e-mail
> > >
> > > multiple patches should either be separate e-mails or attached.  there
> > > should also be a short description of each one individually.
> >
> > Thanks for the feedback, Mike.  What constitutes "multiple patches"?  I
> > did submit 4 different emails, and aside from the fact that the first 2
> > should have been combined into 1, i.e. treated as a whole, the others
> > were split off for specific reasons.
> 
> patches should be logically related.  the patch i replied to, from what i 
> could see, were unrelated changes.

Understandable.

> > I'm not very experienced at posting patches, as you can tell, but I
> > remember reading quite recently that posting patches inline was the
> > preferred way of doing it.  In fact, I'm quite certain that attachments
> > were frowned upon in some quarters.  Regardless, whatever the maintainer
> > wants, the maintainer gets.  I hadn't noticed a preference for one over
> > another.
> 
> going by the "---------- patch start ----------", i thought you had
> multiple 
> markers, but i guess not.
> 
> if you want some good guidelines for how to work with patches, then read
> the SubmittingPatches document that's in the kernel

Next time I'll leave the markers out.  'svn diff' adds a bunch of
separator lines on its own.  Inline patches are easier to review, no? 
Depending on where I am and what email client I'm using, I find
attachments hard to work with.

> > I have no interest in the trunk right now.  If the NPTL code was in the
> > trunk then I would wholeheartedly agree with you 100%.  As it stands
> > today, however, we're talking apples and oranges.
> 
> no we arent.

Umm... yes, we are.  Why would I submit a patch against the trunk when
there is zero chance that update is going to be pulled across into the
nptl branch?  Last I heard (and I could be wrong) the planned merge was
going to go the other way, from nptl --> trunk.  My impression, which
again could be mistaken, was that the nptl branch was not being kept
up-to-date with respect to what's happening in the trunk.  Now, if
you're telling me that a change to the trunk's "foo.h" file is going to
be reflected immediately over in the nptl branch repository, then I
would agree that a non-nptl patch to "foo.h" should go to the trunk. 
Otherwise, the patch belongs in the nptl repository.  What good is a
patch against code you're not compiling?  Please enlighten me if my
understanding is wrong on this point.

> > 4 years of non-working MIPS NPTL isn't enough?  Sorry, I don't mean to
> > be snarky.  Are you aware of the current situation as regards trunk vs.
> > the nptl branch?  Certain aspects of your reply lead me to believe that
> > maybe you are not.
> 
> why dont you read the lines i quoted.  i made no statement at all about
> the mips or ldso or nptl files.  i did however take issue with seemingly
> random unrelated changes in include/ and libc/.  "4 years of non-working MIPS
> NPTL" is hardly relevant when you go around changing attributes and adding
> includes in *completely common code*.
> -mike

They're hardly irrelevant when the code fails to compile without
supporting changes.  Granted, some of them were unnecessary due to an
oversight on my part (please see my replies to Khem and Carmello).  The
attribute change (__inline__ ?) might seem unrelated, and it should
absolutely ALSO go on the trunk, but unless it's ALSO added to the nptl
branch, then putting it on the trunk doesn't do a hell of a lot of good
when I'm trying to compile the nptl branch.

You seem completely unaware of the current dichotomy between the trunk
and the nptl branch.  I don't think they're as close as you seem to
think they are at the moment.  That's what we're working towards, I
thought; the re-integration of the nptl branch back into the trunk. 
Unless it has already happened in the last week without me noticing. 
When that happens we'll all be on the same page and in that context I
have absolutely no problems with any of your criticisms.  We're not at
that point yet AFAICT.

DanE

-- 
http://www.fastmail.fm - IMAP accessible web-mail