Re: Linux 2.5.19

Re: Linux 2.5.19

[James Simmons]

> This is completely wrong - the driver has been tested NOT to work on
> the Integraphics 1682.  As such, please do uncomment these lines.

Due to a error with merging some stuff from a older DJ tree. I fixed it
in the fbdev BK repository.

> In addition, I'm disappointed that no one forwarded the patch for
> maintainer approval PRIOR to submitting it to Linus.

I'm even more disappointed that some people DONT test my patches especially
when I announce them and usually wait about 5 days before pushing them to 
Linus. Some of the changes I have done have been sitting around for months
in the DJ tree. The good news is that people can now look at skeletonfb.c
to see how to port the fbdev drivers to the new api. Of course I have a
feeling most will not bother so I will have to do it for them.



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Russell King]

On Wed, May 29, 2002 at 01:44:12PM -0700, James Simmons wrote:
> > This is completely wrong - the driver has been tested NOT to work on
> > the Integraphics 1682.  As such, please do uncomment these lines.
> 
> Due to a error with merging some stuff from a older DJ tree. I fixed it
> in the fbdev BK repository.

They haven't *been* in any DJ tree.

> > In addition, I'm disappointed that no one forwarded the patch for
> > maintainer approval PRIOR to submitting it to Linus.
> 
> I'm even more disappointed that some people DONT test my patches especially
> when I announce them and usually wait about 5 days before pushing them to 
> Linus. Some of the changes I have done have been sitting around for months
> in the DJ tree. The good news is that people can now look at skeletonfb.c
> to see how to port the fbdev drivers to the new api. Of course I have a
> feeling most will not bother so I will have to do it for them.

Why the fuck should I go around finding and testing peoples trees when I
haven't submitted the stuff to them?  *YOU* shouldn't go around randomly
pulling stuff from maintainers trees without first asking them why the
change hasn't been submitted.

I'm not talking about general maintainence of the cyber2000fb driver here,
or general "keep it working" type changes.  I'm talking about a blatent
"take the version from the rmk patch and submit it to Linus without telling
the maintainer of the code you're buggering with" attitude here.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Martin Dalecki]

Russell King wrote:

> I'm not talking about general maintainence of the cyber2000fb driver here,
> or general "keep it working" type changes.  I'm talking about a blatent
> "take the version from the rmk patch and submit it to Linus without telling
> the maintainer of the code you're buggering with" attitude here.

Dear Russell why don't you just abuse Linus as a spinlock for this kind
of synchronization its his job. No need to get angry at this.
Hey it's developement series time...


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Russell King]

On Thu, May 30, 2002 at 12:22:25AM +0200, Martin Dalecki wrote:
> Dear Russell why don't you just abuse Linus as a spinlock for this kind
> of synchronization its his job. No need to get angry at this.
> Hey it's developement series time...

The fundamental point I'm making is people shouldn't go around taking
changes randomly from maintainers trees, and believing that they know
far better than the maintainer what they're doing, especially when they
don't have the hardware to even try it out, and go submitting these
changes to Linus without even asking about it first...  after the
maintainer has been very careful and explicitly not submitted
the change because they have very good reasons not to.

What if I were to take, say, Mochel's experimental tree and send some
random alpha code to Linus?  Let anarchy rule!

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Martin Dalecki]

Russell King wrote:

> What if I were to take, say, Mochel's experimental tree and send some
> random alpha code to Linus?  Let anarchy rule!

Well ... they have once excuse... if the maintainer is
himself a bit slow on submitting to Linus. Yes I know that's
a matter primary of personal style so there is no need
to discuss about it until down...

About the anarchy - are you sure a Kozaks blood like me
couldn't life up with it ruling? :-).


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Russell King]

On Thu, May 30, 2002 at 12:42:09AM +0200, Martin Dalecki wrote:
> Well ... they have once excuse... if the maintainer is
> himself a bit slow on submitting to Linus. Yes I know that's
> a matter primary of personal style so there is no need
> to discuss about it until down...

You still don't get the point.

1. Patches from cyber2000fb.c have been submitted and the driver in Linus'
   tree up to 2.5.18 is completely up to date and functional, with zero
   known problems.

2. Someone comes along, scans my patch and finds a change.

3. This person takes it upon themselves to solely take that change,
   and, without querying the person who put out the patch set, or
   the maintainer of the driver, decides to send it to Linus without
   testing it in any way since they don't have the hardware to test it.

4. Maintainer, naturally, gets really pissed off.

If you think this is acceptable, why the hell did I bother sending those
IDE DMA changes through you?  After all, you don't need to know about
them because I know better than you, don't I?  *That's* what you're
advocating here, and I'm sure you're going to object to that.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Martin Dalecki]

Russell King wrote:

> If you think this is acceptable, why the hell did I bother sending those
> IDE DMA changes through you?  After all, you don't need to know about
> them because I know better than you, don't I?  *That's* what you're
> advocating here, and I'm sure you're going to object to that.

Well just to make my point clear. I trust you and I thing that you indeed
know better then me on ARM stuff. (At least you can run it on
more then my tinny PSION 5mx... where I still didn't revert to
the original OS, quite cute this little thing under linux :-).
But I wouldn't have minded it at all if you had just sendid
the ARM adjustments directly to Linus!
In the particular case we had it was however good to
have some direct communication in front
just to resolve the API issues. OK?


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[James Simmons]

> > Due to a error with merging some stuff from a older DJ tree. I fixed it
> > in the fbdev BK repository.
> 
> They haven't *been* in any DJ tree.

    Looking threw the many patches I have from people I did grab it from 
patch-2.5.15-rmk1. It is right above the fbcmap.c fix which I did need.
That is where I go it from. Thank you for that fix.  

    While grabbing that fix I noticed what a appeared to be a simple two
line fix for the cyber2000fb driver. Actually I was tempted to port the
whole driver over to the new api but I didn't because I feared you be
ticked off. Especially since I don't have the hardware. The only drivers I
have ported over are the ones that are really simple. I touched the
anakin driver because of this reason. The complex one where I don't have
the hardware I don't touch. Now that we have enough functionally drivers
people can see the new changes needed to be done. 

> Why the fuck should I go around finding and testing peoples trees when I
> haven't submitted the stuff to them?  

    Look here. I'm not looking for trouble or to upset anyone. I know alot
of the fbdev driver maintainers are too busy to properly maintain the
drivers. Several have told me this. Or the drivers have been abandon.
Plus the docs have been shotty for porting to the new api. I am willing to
do extra work and port these drivers to save the maintainers time. I'm
not going to do a perfect port but I do hope what work I did do will help 
them out.  

    I do admit and apologize for not properly saying which drivers have
been altered. I will make a special note of doing that in the future.
Especially since very few actually look at my patches.
           





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Martin Dalecki]

James Simmons wrote:

> 
>     I do admit and apologize for not properly saying which drivers have
> been altered. I will make a special note of doing that in the future.
> Especially since very few actually look at my patches.

Plese don't take silent aprobation for "don't look" :-).
I *like* the patches you do... well just my 0.02EUR.


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Linux 2.5.19

[Russell King]

On Thu, May 30, 2002 at 12:29:26AM +0200, Martin Dalecki wrote:
> Plese don't take silent aprobation for "don't look" :-).
> I *like* the patches you do... well just my 0.02EUR.

This is about people who think they're god nicking patches from
the author and maintainer of drivers and bypassing the maintainer
completely.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Framebuffer policy [ was Re: Linux 2.5.19]

[James Simmons]

> This is about people who think they're god nicking patches from
> the author and maintainer of drivers and bypassing the maintainer
> completely.

Please no fighting. It is clear the problem is the lack of order here.
I understand how Russell feels. Most of the time people send in new fbdev
drivers or good size patches without consulting me or Geert first. I have
to say it has gotten better. So here goes for policy time:

--------------------------------------------------------------------
             Framebuffer driver policy.

1) Basic one or few line fixes for drivers can go straight into the
   kernel. Please don't abuse this.

2) All new drivers must be posted to the fbdev developement list for
   peer review. Me and/or geert have final fword about them going in.
   Please note we do get busy so just harass me about your driver. I
   will not be offended and it pushs me to go do it. I'm the type of
   person if I don't do it right away I will forget.

   linux-fbdev-devel@lists.sourceforge.net

3) Large changes should be posted to both the framebuffer list and the
   kernel mailing list as well to the framebuffer author if they
   are know. Again it is for peer review and wide scale testing. We 
   need to make clear what drivers where effect. And yes if you are the 
   maintainer of a driver you should mail yourself. It makes it easier
   for users to reply to you directly.  

If no one follows these rules then their changes will be ignored. No
exceptions including for myself.

-----------------------------------------------------------------
How does this sound? Again sorry about the confusion.




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm