Re: [ros-dev] [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented

[Ged Murphy]

I don't mean to sound like a broken record, and I also understand that the project allows people to work on whatever they want to. But with the project in such a state at the moment, is a pcmcia bus driver really the best thing to be working on?
I'm all for project freedom, but you would hope people to have the diligence to work on areas which might help to stop the project from failing.

Maybe I just don't get it anymore and I'm behind the times, but what happened to the days when people used to work on important things?

Your nagging ex-dev,
Ged.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 15 April 2010 02:59
To: [e-mail]
Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented

Author: cgutman
Date: Thu Apr 15 03:59:15 2010
New Revision: 46876

URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
Log:
[PCMCIA]
- Add a mostly stubbed PCMCIA driver
- pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented

Added:
    trunk/reactos/drivers/bus/pcmcia/
    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
Modified:
    trunk/reactos/drivers/bus/directory.rbuild

[Aleksey Bragin]

I fully agree with Ged. I know it's fun to create something from  
scratch (I used and will still do, of course) and work in an explored  
area, however I think there should be some control. If you really  
want to work on that and nothing else - we have rosapps/drivers. In  
my opinion, trunk has no place for non-working drivers which aren't  
really a top priority (at least, I didn't include fastfat_new to the  
build process so noone wastes time compiling a driver which is needed  
only by 2 or 3 developers).

WBR,
Aleksey.

On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> I don't mean to sound like a broken record, and I also understand  
> that the project allows people to work on whatever they want to.  
> But with the project in such a state at the moment, is a pcmcia bus  
> driver really the best thing to be working on?
> I'm all for project freedom, but you would hope people to have the  
> diligence to work on areas which might help to stop the project  
> from failing.
>
> Maybe I just don't get it anymore and I'm behind the times, but  
> what happened to the days when people used to work on important  
> things?
>
> Your nagging ex-dev,
> Ged.
>
> -----Original Message-----
> From: [e-mail] [mailto:ros-diffs- 
> [e-mail]] On Behalf Of [e-mail]
> Sent: 15 April 2010 02:59
> To: [e-mail]
> Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly  
> stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c  
> are completely unimplemented
>
> Author: cgutman
> Date: Thu Apr 15 03:59:15 2010
> New Revision: 46876
>
> URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> Log:
> [PCMCIA]
> Add a mostly stubbed PCMCIA driver
> pcmcia.c is complete but fdo.c and pdo.c are completely
>
> unimplemented
>
> Added:
>     trunk/reactos/drivers/bus/pcmcia/
>     trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
>     trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
>     trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
>     trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
>     trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
>     trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> Modified:
>     trunk/reactos/drivers/bus/directory.rbuild
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

ReactOS has PCMCIA support before USB
lol :)

On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin [e-mail]:
> I fully agree with Ged. I know it's fun to create something from scratch (I
> used and will still do, of course) and work in an explored area, however I
> think there should be some control. If you really want to work on that and
> nothing else - we have rosapps/drivers. In my opinion, trunk has no place
> for non-working drivers which aren't really a top priority (at least, I
> didn't include fastfat_new to the build process so noone wastes time
> compiling a driver which is needed only by 2 or 3 developers).
>
> WBR,
> Aleksey.
>
> On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
>
> I don't mean to sound like a broken record, and I also understand that the
> > project allows people to work on whatever they want to. But with the project
> > in such a state at the moment, is a pcmcia bus driver really the best thing
> > to be working on?
> > I'm all for project freedom, but you would hope people to have the
> > diligence to work on areas which might help to stop the project from
> > failing.
> >
> > Maybe I just don't get it anymore and I'm behind the times, but what
> > happened to the days when people used to work on important things?
> >
> > Your nagging ex-dev,
> > Ged.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of [e-mail]
> > Sent: 15 April 2010 02:59
> > To: [e-mail]
> > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely
> > unimplemented
> >
> > Author: cgutman
> > Date: Thu Apr 15 03:59:15 2010
> > New Revision: 46876
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > Log:
> > [PCMCIA]
> > Add a mostly stubbed PCMCIA driver
> > pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented
> >
> > Added:
> >    trunk/reactos/drivers/bus/pcmcia/
> >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > Modified:
> >    trunk/reactos/drivers/bus/directory.rbuild
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Andrew Faulds]

You mean we're supporting an interface no-one needs before the biggest gap
in ReactOS I/O support?

2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> ReactOS has PCMCIA support before USB
> lol :)
>
> On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin [e-mail]:
> > I fully agree with Ged. I know it's fun to create something from scratch
> > (I used and will still do, of course) and work in an explored area, however
> > I think there should be some control. If you really want to work on that and
> > nothing else - we have rosapps/drivers. In my opinion, trunk has no place
> > for non-working drivers which aren't really a top priority (at least, I
> > didn't include fastfat_new to the build process so noone wastes time
> > compiling a driver which is needed only by 2 or 3 developers).
> >
> > WBR,
> > Aleksey.
> >
> > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> >
> > I don't mean to sound like a broken record, and I also understand that
> > > the project allows people to work on whatever they want to. But with the
> > > project in such a state at the moment, is a pcmcia bus driver really the
> > > best thing to be working on?
> > > I'm all for project freedom, but you would hope people to have the
> > > diligence to work on areas which might help to stop the project from
> > > failing.
> > >
> > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > happened to the days when people used to work on important things?
> > >
> > > Your nagging ex-dev,
> > > Ged.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:
> > > [e-mail]] On Behalf Of [e-mail]
> > > Sent: 15 April 2010 02:59
> > > To: [e-mail]
> > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely
> > > unimplemented
> > >
> > > Author: cgutman
> > > Date: Thu Apr 15 03:59:15 2010
> > > New Revision: 46876
> > >
> > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > Log:
> > > [PCMCIA]
> > > Add a mostly stubbed PCMCIA driver
> > > pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented
> > >
> > > Added:
> > >    trunk/reactos/drivers/bus/pcmcia/
> > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > Modified:
> > >    trunk/reactos/drivers/bus/directory.rbuild
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Andrew Faulds (andrewros)
http://ajf.me/

[Peter Millerchip]

To be fair:

1. The guy donated his code to ReactOS. Think of it like a gift to us
- it might not be what we really wanted, but it's still rude to insult
a gift.

2. This isn't "support" for PCMCIA, it's a stub - he said so himself.
ReactOS does not support PCMCIA yet.

3. Windows supported PCMCIA before USB, and we are just copying
Windows after all! :)

On 15 April 2010 10:11, Andrew Faulds [e-mail] wrote:
> You mean we're supporting an interface no-one needs before the biggest gap
> in ReactOS I/O support?
>
> 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > ReactOS has PCMCIA support before USB
> > lol :)
> >
> > On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin [e-mail]
> > wrote:
> > > I fully agree with Ged. I know it's fun to create something from scratch
> > > (I used and will still do, of course) and work in an explored area, however
> > > I think there should be some control. If you really want to work on that and
> > > nothing else - we have rosapps/drivers. In my opinion, trunk has no place
> > > for non-working drivers which aren't really a top priority (at least, I
> > > didn't include fastfat_new to the build process so noone wastes time
> > > compiling a driver which is needed only by 2 or 3 developers).
> > >
> > > WBR,
> > > Aleksey.
> > >
> > > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > > I don't mean to sound like a broken record, and I also understand that
> > > > the project allows people to work on whatever they want to. But with the
> > > > project in such a state at the moment, is a pcmcia bus driver really the
> > > > best thing to be working on?
> > > > I'm all for project freedom, but you would hope people to have the
> > > > diligence to work on areas which might help to stop the project from
> > > > failing.
> > > >
> > > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > > happened to the days when people used to work on important things?
> > > >
> > > > Your nagging ex-dev,
> > > > Ged.
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of [e-mail]
> > > > Sent: 15 April 2010 02:59
> > > > To: [e-mail]
> > > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely
> > > > unimplemented
> > > >
> > > > Author: cgutman
> > > > Date: Thu Apr 15 03:59:15 2010
> > > > New Revision: 46876
> > > >
> > > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > > Log:
> > > > [PCMCIA]
> > > > Add a mostly stubbed PCMCIA driver
> > > > pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented
> > > >
> > > > Added:
> > > >    trunk/reactos/drivers/bus/pcmcia/
> > > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > > Modified:
> > > >    trunk/reactos/drivers/bus/directory.rbuild
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> Andrew Faulds (andrewros)
> http://ajf.me/
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Andrew Faulds]

Yes, but we get "donations" on all sorts of unnecessary things.
We really need "donations" in *useful areas* like, say, USB.

On 15 April 2010 10:25, Peter Millerchip [e-mail] wrote:
> To be fair:
> The guy donated his code to ReactOS. Think of it like a gift to us
> it might not be what we really wanted, but it's still rude to insult
>
> a gift.
> This isn't "support" for PCMCIA, it's a stub - he said so himself.
>
> ReactOS does not support PCMCIA yet.
> Windows supported PCMCIA before USB, and we are just copying
>
> Windows after all! :)
>
> On 15 April 2010 10:11, Andrew Faulds [e-mail] wrote:
> > You mean we're supporting an interface no-one needs before the biggest
>
> gap
> > in ReactOS I/O support?
> >
> > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > > ReactOS has PCMCIA support before USB
> > > lol :)
> > >
> > > On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin [e-mail]
> > > wrote:
> > > > I fully agree with Ged. I know it's fun to create something from
>
> scratch
> > > > (I used and will still do, of course) and work in an explored area,
>
> however
> > > > I think there should be some control. If you really want to work on
>
> that and
> > > > nothing else - we have rosapps/drivers. In my opinion, trunk has no
>
> place
> > > > for non-working drivers which aren't really a top priority (at least, I
> > > > didn't include fastfat_new to the build process so noone wastes time
> > > > compiling a driver which is needed only by 2 or 3 developers).
> > > >
> > > > WBR,
> > > > Aleksey.
> > > >
> > > > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > > > I don't mean to sound like a broken record, and I also understand that
> > > > > the project allows people to work on whatever they want to. But with
>
> the
> > > > > project in such a state at the moment, is a pcmcia bus driver really
>
> the
> > > > > best thing to be working on?
> > > > > I'm all for project freedom, but you would hope people to have the
> > > > > diligence to work on areas which might help to stop the project from
> > > > > failing.
> > > > >
> > > > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > > > happened to the days when people used to work on important things?
> > > > >
> > > > > Your nagging ex-dev,
> > > > > Ged.
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of
>
> [e-mail]
> > > > > Sent: 15 April 2010 02:59
> > > > > To: [e-mail]
> > > > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > > > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
>
> completely
> > > > > unimplemented
> > > > >
> > > > > Author: cgutman
> > > > > Date: Thu Apr 15 03:59:15 2010
> > > > > New Revision: 46876
> > > > >
> > > > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > > > Log:
> > > > > [PCMCIA]
> > > > > Add a mostly stubbed PCMCIA driver
> > > > > pcmcia.c is complete but fdo.c and pdo.c are completely
>
> unimplemented
> > > > > Added:
> > > > >    trunk/reactos/drivers/bus/pcmcia/
> > > > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > > > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > > > Modified:
> > > > >    trunk/reactos/drivers/bus/directory.rbuild
> > > > >
> > > > > Ros-dev mailing list
> > > > > [e-mail]
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > --
> > Andrew Faulds (andrewros)
> > http://ajf.me/
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Andrew Faulds (andrewros)
http://ajf.me/

[Javier Agustìn Fernàndez Arroyo]

well, it will be useful whenever it has to :)
so, i dont see it as a bad commit after all, just funny :P

On Thu, Apr 15, 2010 at 11:28 AM, Andrew Faulds [e-mail]:
> Yes, but we get "donations" on all sorts of unnecessary things.
> We really need "donations" in *useful areas* like, say, USB.
>
> On 15 April 2010 10:25, Peter Millerchip [e-mail]:
> > To be fair:
> > The guy donated his code to ReactOS. Think of it like a gift to us
> > it might not be what we really wanted, but it's still rude to insult
> >
> > a gift.
> > This isn't "support" for PCMCIA, it's a stub - he said so himself.
> >
> > ReactOS does not support PCMCIA yet.
> > Windows supported PCMCIA before USB, and we are just copying
> >
> > Windows after all! :)
> >
> > On 15 April 2010 10:11, Andrew Faulds [e-mail] wrote:
> > > You mean we're supporting an interface no-one needs before the biggest
> >
> > gap
> > > in ReactOS I/O support?
> > >
> > > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > > > ReactOS has PCMCIA support before USB
> > > > lol :)
> > > >
> > > > On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin [e-mail]
> > > > wrote:
> > > > > I fully agree with Ged. I know it's fun to create something from
> >
> > scratch
> > > > > (I used and will still do, of course) and work in an explored area,
> >
> > however
> > > > > I think there should be some control. If you really want to work on
> >
> > that and
> > > > > nothing else - we have rosapps/drivers. In my opinion, trunk has no
> >
> > place
> > > > > for non-working drivers which aren't really a top priority (at least,
> >
> > I
> > > > > didn't include fastfat_new to the build process so noone wastes time
> > > > > compiling a driver which is needed only by 2 or 3 developers).
> > > > >
> > > > > WBR,
> > > > > Aleksey.
> > > > >
> > > > > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > > > > I don't mean to sound like a broken record, and I also understand
> >
> > that
> > > > > > the project allows people to work on whatever they want to. But with
> >
> > the
> > > > > > project in such a state at the moment, is a pcmcia bus driver really
> >
> > the
> > > > > > best thing to be working on?
> > > > > > I'm all for project freedom, but you would hope people to have the
> > > > > > diligence to work on areas which might help to stop the project from
> > > > > > failing.
> > > > > >
> > > > > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > > > > happened to the days when people used to work on important things?
> > > > > >
> > > > > > Your nagging ex-dev,
> > > > > > Ged.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > > > [mailto:[e-mail]] On Behalf Of
> >
> > [e-mail]
> > > > > > Sent: 15 April 2010 02:59
> > > > > > To: [e-mail]
> > > > > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > > > > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
> >
> > completely
> > > > > > unimplemented
> > > > > >
> > > > > > Author: cgutman
> > > > > > Date: Thu Apr 15 03:59:15 2010
> > > > > > New Revision: 46876
> > > > > >
> > > > > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > > > > Log:
> > > > > > [PCMCIA]
> > > > > > Add a mostly stubbed PCMCIA driver
> > > > > > pcmcia.c is complete but fdo.c and pdo.c are completely
> >
> > unimplemented
> > > > > > Added:
> > > > > >    trunk/reactos/drivers/bus/pcmcia/
> > > > > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > > > > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > > > > Modified:
> > > > > >    trunk/reactos/drivers/bus/directory.rbuild
> > > > > >
> > > > > > Ros-dev mailing list
> > > > > > [e-mail]
> > > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > > >
> > > > > Ros-dev mailing list
> > > > > [e-mail]
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > --
> > > Andrew Faulds (andrewros)
> > > http://ajf.me/
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> Andrew Faulds (andrewros)
> http://ajf.me/
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Samuel serapion]

Javier this isn't funny. ReactOS is serious business.

2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> well, it will be useful whenever it has to :)
> so, i dont see it as a bad commit after all, just funny :P
>
> On Thu, Apr 15, 2010 at 11:28 AM, Andrew Faulds [e-mail]:
> > Yes, but we get "donations" on all sorts of unnecessary things.
> > We really need "donations" in *useful areas* like, say, USB.
> >
> > On 15 April 2010 10:25, Peter Millerchip [e-mail]:
> > > To be fair:
> > > The guy donated his code to ReactOS. Think of it like a gift to us
> > > it might not be what we really wanted, but it's still rude to insult
> > >
> > > a gift.
> > > This isn't "support" for PCMCIA, it's a stub - he said so himself.
> > >
> > > ReactOS does not support PCMCIA yet.
> > > Windows supported PCMCIA before USB, and we are just copying
> > >
> > > Windows after all! :)
> > >
> > > On 15 April 2010 10:11, Andrew Faulds [e-mail] wrote:
> > > > You mean we're supporting an interface no-one needs before the biggest
> > >
> > > gap
> > > > in ReactOS I/O support?
> > > >
> > > > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > > > > ReactOS has PCMCIA support before USB
> > > > > lol :)
> > > > >
> > > > > On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin <[e-mail]
> > > > > wrote:
> > > > > > I fully agree with Ged. I know it's fun to create something from
> > >
> > > scratch
> > > > > > (I used and will still do, of course) and work in an explored area,
> > >
> > > however
> > > > > > I think there should be some control. If you really want to work on
> > >
> > > that and
> > > > > > nothing else - we have rosapps/drivers. In my opinion, trunk has no
> > >
> > > place
> > > > > > for non-working drivers which aren't really a top priority (at least,
> > >
> > > I
> > > > > > didn't include fastfat_new to the build process so noone wastes time
> > > > > > compiling a driver which is needed only by 2 or 3 developers).
> > > > > >
> > > > > > WBR,
> > > > > > Aleksey.
> > > > > >
> > > > > > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > > > >
> > > > > > > I don't mean to sound like a broken record, and I also understand
> > >
> > > that
> > > > > > > the project allows people to work on whatever they want to. But with
> > >
> > > the
> > > > > > > project in such a state at the moment, is a pcmcia bus driver really
> > >
> > > the
> > > > > > > best thing to be working on?
> > > > > > > I'm all for project freedom, but you would hope people to have the
> > > > > > > diligence to work on areas which might help to stop the project from
> > > > > > > failing.
> > > > > > >
> > > > > > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > > > > > happened to the days when people used to work on important things?
> > > > > > >
> > > > > > >
> > > > > > > Your nagging ex-dev,
> > > > > > > Ged.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [e-mail]
> > > > > > > [mailto:[e-mail]] On Behalf Of
> > >
> > > [e-mail]
> > > > > > > Sent: 15 April 2010 02:59
> > > > > > > To: [e-mail]
> > > > > > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly
> > >
> > > stubbed
> > > > > > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
> > >
> > > completely
> > > > > > > unimplemented
> > > > > > >
> > > > > > > Author: cgutman
> > > > > > > Date: Thu Apr 15 03:59:15 2010
> > > > > > > New Revision: 46876
> > > > > > >
> > > > > > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > > > > > Log:
> > > > > > > [PCMCIA]
> > > > > > > - Add a mostly stubbed PCMCIA driver
> > > > > > > - pcmcia.c is complete but fdo.c and pdo.c are completely
> > >
> > > unimplemented
> > > > > > >
> > > > > > > Added:
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > > > > > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > > > > > Modified:
> > > > > > >    trunk/reactos/drivers/bus/directory.rbuild
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ros-dev mailing list
> > > > > > > [e-mail]
> > > > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > > > >
> > > > > > Ros-dev mailing list
> > > > > > [e-mail]
> > > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > > >
> > > > > Ros-dev mailing list
> > > > > [e-mail]
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > > --
> > > > Andrew Faulds (andrewros)
> > > > http://ajf.me/
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > --
> > Andrew Faulds (andrewros)
> > http://ajf.me/
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

hm?

On Thu, Apr 15, 2010 at 8:33 PM, Samuel serapion [e-mail]:
> Javier this isn't funny. ReactOS is serious business.
>
> 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > well, it will be useful whenever it has to :)
> > so, i dont see it as a bad commit after all, just funny :P
> >
> > On Thu, Apr 15, 2010 at 11:28 AM, Andrew Faulds [e-mail]:
> > > Yes, but we get "donations" on all sorts of unnecessary things.
> > > We really need "donations" in *useful areas* like, say, USB.
> > >
> > > On 15 April 2010 10:25, Peter Millerchip [e-mail]:
> > > > To be fair:
> > > > The guy donated his code to ReactOS. Think of it like a gift to us
> > > > it might not be what we really wanted, but it's still rude to insult
> > > >
> > > > a gift.
> > > > This isn't "support" for PCMCIA, it's a stub - he said so himself.
> > > >
> > > > ReactOS does not support PCMCIA yet.
> > > > Windows supported PCMCIA before USB, and we are just copying
> > > >
> > > > Windows after all! :)
> > > >
> > > > On 15 April 2010 10:11, Andrew Faulds [e-mail] wrote:
> > > > > You mean we're supporting an interface no-one needs before the biggest
> > > >
> > > > gap
> > > > > in ReactOS I/O support?
> > > > >
> > > > > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]
> > > > > > ReactOS has PCMCIA support before USB
> > > > > > lol :)
> > > > > >
> > > > > > On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin <
> > > >
> > > > [e-mail]>
> > > > > > wrote:
> > > > > > >
> > > > > > > I fully agree with Ged. I know it's fun to create something from
> > > >
> > > > scratch
> > > > > > > (I used and will still do, of course) and work in an explored area,
> > > >
> > > > however
> > > > > > > I think there should be some control. If you really want to work on
> > > >
> > > > that and
> > > > > > > nothing else - we have rosapps/drivers. In my opinion, trunk has no
> > > >
> > > > place
> > > > > > > for non-working drivers which aren't really a top priority (at
> > > >
> > > > least, I
> > > > > > > didn't include fastfat_new to the build process so noone wastes time
> > > > > > > compiling a driver which is needed only by 2 or 3 developers).
> > > > > > >
> > > > > > > WBR,
> > > > > > > Aleksey.
> > > > > > >
> > > > > > > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > > > > >
> > > > > > >> I don't mean to sound like a broken record, and I also understand
> > > >
> > > > that
> > > > > > >> the project allows people to work on whatever they want to. But
> > > >
> > > > with the
> > > > > > >> project in such a state at the moment, is a pcmcia bus driver
> > > >
> > > > really the
> > > > > > >> best thing to be working on?
> > > > > > >> I'm all for project freedom, but you would hope people to have the
> > > > > > >> diligence to work on areas which might help to stop the project
> > > >
> > > > from
> > > > > > >> failing.
> > > > > > >>
> > > > > > >> Maybe I just don't get it anymore and I'm behind the times, but
> > > >
> > > > what
> > > > > > >> happened to the days when people used to work on important things?
> > > > > > >>
> > > > > > >>
> > > > > > >> Your nagging ex-dev,
> > > > > > >> Ged.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> -----Original Message-----
> > > > > > >> From: [e-mail]
> > > > > > >> [mailto:[e-mail]] On Behalf Of
> > > >
> > > > [e-mail]
> > > > > > >> Sent: 15 April 2010 02:59
> > > > > > >> To: [e-mail]
> > > > > > >> Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly
> > > >
> > > > stubbed
> > > > > > >> PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
> > > >
> > > > completely
> > > > > > >> unimplemented
> > > > > > >>
> > > > > > >> Author: cgutman
> > > > > > >> Date: Thu Apr 15 03:59:15 2010
> > > > > > >> New Revision: 46876
> > > > > > >>
> > > > > > >> URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > > > > >> Log:
> > > > > > >> [PCMCIA]
> > > > > > >> - Add a mostly stubbed PCMCIA driver
> > > > > > >> - pcmcia.c is complete but fdo.c and pdo.c are completely
> > > >
> > > > unimplemented
> > > > > > >>
> > > > > > >> Added:
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > > > > > >>    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > > > > >> Modified:
> > > > > > >>    trunk/reactos/drivers/bus/directory.rbuild
> > > > > > >>
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> Ros-dev mailing list
> > > > > > >> [e-mail]
> > > > > > >> http://www.reactos.org/mailman/listinfo/ros-dev
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Ros-dev mailing list
> > > > > > > [e-mail]
> > > > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > > > >
> > > > > > Ros-dev mailing list
> > > > > > [e-mail]
> > > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > > >
> > > > > --
> > > > > Andrew Faulds (andrewros)
> > > > > http://ajf.me/
> > > > >
> > > > > Ros-dev mailing list
> > > > > [e-mail]
> > > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > --
> > > Andrew Faulds (andrewros)
> > > http://ajf.me/
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Millerchip]

Yes, I agree too - trunk should ideally not contain non-working code.
Maybe non-working drivers belong in a branch until they've been fully
tested?

Maybe trunk should be locked to everyone except a "trunk manager" who
accepts patches from people, or merges different branches in to trunk.
That way trunk can remain stable and lean. Would that be a good idea,
or a bad one?

On 15 April 2010 09:46, Aleksey Bragin [e-mail] wrote:
> I fully agree with Ged. I know it's fun to create something from scratch (I
> used and will still do, of course) and work in an explored area, however I
> think there should be some control. If you really want to work on that and
> nothing else - we have rosapps/drivers. In my opinion, trunk has no place
> for non-working drivers which aren't really a top priority (at least, I
> didn't include fastfat_new to the build process so noone wastes time
> compiling a driver which is needed only by 2 or 3 developers).
>
> WBR,
> Aleksey.
>
> On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > I don't mean to sound like a broken record, and I also understand that the
> > project allows people to work on whatever they want to. But with the project
> > in such a state at the moment, is a pcmcia bus driver really the best thing
> > to be working on?
> > I'm all for project freedom, but you would hope people to have the
> > diligence to work on areas which might help to stop the project from
> > failing.
> >
> > Maybe I just don't get it anymore and I'm behind the times, but what
> > happened to the days when people used to work on important things?
> >
> > Your nagging ex-dev,
> > Ged.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of [e-mail]
> > Sent: 15 April 2010 02:59
> > To: [e-mail]
> > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely
> > unimplemented
> >
> > Author: cgutman
> > Date: Thu Apr 15 03:59:15 2010
> > New Revision: 46876
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > Log:
> > [PCMCIA]
> > Add a mostly stubbed PCMCIA driver
> > pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented
> >
> > Added:
> >    trunk/reactos/drivers/bus/pcmcia/
> >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > Modified:
> >    trunk/reactos/drivers/bus/directory.rbuild
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

bad one, i guess
that would slow down development a lot

On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip <
[e-mail]> wrote:
> Yes, I agree too - trunk should ideally not contain non-working code.
> Maybe non-working drivers belong in a branch until they've been fully
> tested?
>
> Maybe trunk should be locked to everyone except a "trunk manager" who
> accepts patches from people, or merges different branches in to trunk.
> That way trunk can remain stable and lean. Would that be a good idea,
> or a bad one?
>
> On 15 April 2010 09:46, Aleksey Bragin [e-mail] wrote:
> > I fully agree with Ged. I know it's fun to create something from scratch
>
> (I
> > used and will still do, of course) and work in an explored area, however
>
> I
> > think there should be some control. If you really want to work on that
>
> and
> > nothing else - we have rosapps/drivers. In my opinion, trunk has no place
> > for non-working drivers which aren't really a top priority (at least, I
> > didn't include fastfat_new to the build process so noone wastes time
> > compiling a driver which is needed only by 2 or 3 developers).
> >
> > WBR,
> > Aleksey.
> >
> > On Apr 15, 2010, at 11:05 AM, Ged Murphy wrote:
> > > I don't mean to sound like a broken record, and I also understand that
>
> the
> > > project allows people to work on whatever they want to. But with the
>
> project
> > > in such a state at the moment, is a pcmcia bus driver really the best
>
> thing
> > > to be working on?
> > > I'm all for project freedom, but you would hope people to have the
> > > diligence to work on areas which might help to stop the project from
> > > failing.
> > >
> > > Maybe I just don't get it anymore and I'm behind the times, but what
> > > happened to the days when people used to work on important things?
> > >
> > > Your nagging ex-dev,
> > > Ged.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:
>
> [e-mail]]
> > > On Behalf Of [e-mail]
> > > Sent: 15 April 2010 02:59
> > > To: [e-mail]
> > > Subject: [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly stubbed
> > > PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are completely
> > > unimplemented
> > >
> > > Author: cgutman
> > > Date: Thu Apr 15 03:59:15 2010
> > > New Revision: 46876
> > >
> > > URL: http://svn.reactos.org/svn/reactos?rev=46876&view=rev
> > > Log:
> > > [PCMCIA]
> > > Add a mostly stubbed PCMCIA driver
> > > pcmcia.c is complete but fdo.c and pdo.c are completely unimplemented
> > >
> > > Added:
> > >    trunk/reactos/drivers/bus/pcmcia/
> > >    trunk/reactos/drivers/bus/pcmcia/fdo.c   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.c   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.h   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rbuild   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pcmcia.rc   (with props)
> > >    trunk/reactos/drivers/bus/pcmcia/pdo.c   (with props)
> > > Modified:
> > >    trunk/reactos/drivers/bus/directory.rbuild
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Millerchip]

No it wouldn't slow down development, people would just develop on
branches at the same speed as they do now. It would just mean that
trunk would only get the features when they work, rather than having
incomplete and untested code littering it.

Don't knock it, it works for the Linux kernel devs ;)

2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]:
> bad one, i guess
> that would slow down development a lot
>
> On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip
> [e-mail] wrote:
> > Yes, I agree too - trunk should ideally not contain non-working code.
> > Maybe non-working drivers belong in a branch until they've been fully
> > tested?
> >
> > Maybe trunk should be locked to everyone except a "trunk manager" who
> > accepts patches from people, or merges different branches in to trunk.
> > That way trunk can remain stable and lean. Would that be a good idea,
> > or a bad one?

[Andrew Faulds]

But wait with Linux doesn't it work because there's one person ultimately
controlling it?

On 15 April 2010 10:37, Peter Millerchip [e-mail] wrote:
> No it wouldn't slow down development, people would just develop on
> branches at the same speed as they do now. It would just mean that
> trunk would only get the features when they work, rather than having
> incomplete and untested code littering it.
>
> Don't knock it, it works for the Linux kernel devs ;)
>
> 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]:
> > bad one, i guess
> > that would slow down development a lot
> >
> > On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip
> > [e-mail] wrote:
> > > Yes, I agree too - trunk should ideally not contain non-working code.
> > > Maybe non-working drivers belong in a branch until they've been fully
> > > tested?
> > >
> > > Maybe trunk should be locked to everyone except a "trunk manager" who
> > > accepts patches from people, or merges different branches in to trunk.
> > > That way trunk can remain stable and lean. Would that be a good idea,
> > > or a bad one?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Andrew Faulds (andrewros)
http://ajf.me/

[Peter Millerchip]

Exactly - so surely if we nominate a "trunk manager" they would
perform that role? That would work, wouldn't it? Their job would be to
accept fully tested patches into trunk, or reject immature or broken
patches. They would be like the "Linus" of ReactOS, the guy who says
whether stuff is good enough to get into trunk or not.

On 15 April 2010 10:41, Andrew Faulds [e-mail] wrote:
> But wait with Linux doesn't it work because there's one person ultimately
> controlling it?
>
> On 15 April 2010 10:37, Peter Millerchip [e-mail] wrote:
> > No it wouldn't slow down development, people would just develop on
> > branches at the same speed as they do now. It would just mean that
> > trunk would only get the features when they work, rather than having
> > incomplete and untested code littering it.
> >
> > Don't knock it, it works for the Linux kernel devs ;)
> >
> > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]:
> > > bad one, i guess
> > > that would slow down development a lot
> > >
> > > On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip
> > > [e-mail] wrote:
> > > > Yes, I agree too - trunk should ideally not contain non-working code.
> > > > Maybe non-working drivers belong in a branch until they've been fully
> > > > tested?
> > > >
> > > > Maybe trunk should be locked to everyone except a "trunk manager" who
> > > > accepts patches from people, or merges different branches in to trunk.
> > > > That way trunk can remain stable and lean. Would that be a good idea,
> > > > or a bad one?
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> Andrew Faulds (andrewros)
> http://ajf.me/
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Andrew Faulds]

Yes. We need a "Linus Torvalds" for ReactOS. If it worked for Linux, it'll
work for ReactOS.

On 15 April 2010 10:53, Peter Millerchip [e-mail] wrote:
> Exactly - so surely if we nominate a "trunk manager" they would
> perform that role? That would work, wouldn't it? Their job would be to
> accept fully tested patches into trunk, or reject immature or broken
> patches. They would be like the "Linus" of ReactOS, the guy who says
> whether stuff is good enough to get into trunk or not.
>
> On 15 April 2010 10:41, Andrew Faulds [e-mail] wrote:
> > But wait with Linux doesn't it work because there's one person ultimately
> > controlling it?
> >
> > On 15 April 2010 10:37, Peter Millerchip [e-mail]
>
> wrote:
> > > No it wouldn't slow down development, people would just develop on
> > > branches at the same speed as they do now. It would just mean that
> > > trunk would only get the features when they work, rather than having
> > > incomplete and untested code littering it.
> > >
> > > Don't knock it, it works for the Linux kernel devs ;)
> > >
> > > 2010/4/15 Javier Agustìn Fernàndez Arroyo [e-mail]:
> > > > bad one, i guess
> > > > that would slow down development a lot
> > > >
> > > > On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip
> > > > [e-mail] wrote:
> > > > > Yes, I agree too - trunk should ideally not contain non-working code.
> > > > > Maybe non-working drivers belong in a branch until they've been fully
> > > > > tested?
> > > > >
> > > > > Maybe trunk should be locked to everyone except a "trunk manager" who
> > > > > accepts patches from people, or merges different branches in to
>
> trunk.
> > > > > That way trunk can remain stable and lean. Would that be a good idea,
> > > > > or a bad one?
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > --
> > Andrew Faulds (andrewros)
> > http://ajf.me/
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Andrew Faulds (andrewros)
http://ajf.me/

[Daniel Reimer]

I am for writing a PCMCIA Driver in the current state. Most here don't 
see the argument I see every day. Debugging more recent Notebooks. You 
all still should know what a pain it was to get ROS running on my CLT 
2010 machine without any serial Port. UniATA Bug here, Sound problems 
there... Wonderful. Well, it had a PCMCIA and there are COM to PCMCIA 
Cards and they are quite cheap. This would help us getting useful debug 
information from many new machines, where it was impossible before. OK, 
USB will add that to even more, but its already being worked on USB, so 
chill and let him be.

Just my 2 cents~~~

[Ged Murphy]

So the whole project should continue to stagnate, but that's ok because you
can get debug info off your notebook...

I think it's much more important to get things moving forward in virtual
machines than your laptops debug output.

Ged.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Daniel Reimer
Sent: 15 April 2010 11:17
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly
stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
completely unimplemented

I am for writing a PCMCIA Driver in the current state. Most here don't 
see the argument I see every day. Debugging more recent Notebooks. You 
all still should know what a pain it was to get ROS running on my CLT 
2010 machine without any serial Port. UniATA Bug here, Sound problems 
there... Wonderful. Well, it had a PCMCIA and there are COM to PCMCIA 
Cards and they are quite cheap. This would help us getting useful debug 
information from many new machines, where it was impossible before. OK, 
USB will add that to even more, but its already being worked on USB, so 
chill and let him be.

Just my 2 cents~~~

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Daniel Reimer]

Good luck in finding hobby programmers who do what you tell em to do. 
As long as you cant pay them, its hard to force them in direction. If 
they loose interest or fun in coding for ROS then we are not just 
stagnating, we are deserted. If you wanna risk this, feel free to. I 
cant and wont stop you.

And I still think PCMCIA is important and useful right now.

Well, you think VMs are more important than Real HW? You were kidding, 
right?! You were not at CLT 2010 so you might not know what ppl want out 
there. 75% of all questions were about real HW support and support for 
specific hardware which fails right now. So maybe you think that recent 
PnP and HAL fixes were badly used time, too? Real HW support is at least 
as important as internal improvements. Both is needed for a useable OS. 
And for real HW support we need, USB, PCMCIA, GFX Drivers running, WIFI 
, Printing and maybe even dial up. Especially the first two are 
important for debugging PCs without a Serial Port, which is a big 
problem right now.

Am 15.04.2010 12:39, schrieb Ged Murphy:
> So the whole project should continue to stagnate, but that's ok because you
> can get debug info off your notebook...
>
> I think it's much more important to get things moving forward in virtual
> machines than your laptops debug output.
>
> Ged.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Daniel Reimer
> Sent: 15 April 2010 11:17
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [cgutman] 46876: [PCMCIA] - Add a mostly
> stubbed PCMCIA driver - pcmcia.c is complete but fdo.c and pdo.c are
> completely unimplemented
>
> I am for writing a PCMCIA Driver in the current state. Most here don't
> see the argument I see every day. Debugging more recent Notebooks. You
> all still should know what a pain it was to get ROS running on my CLT
> 2010 machine without any serial Port. UniATA Bug here, Sound problems
> there... Wonderful. Well, it had a PCMCIA and there are COM to PCMCIA
> Cards and they are quite cheap. This would help us getting useful debug
> information from many new machines, where it was impossible before. OK,
> USB will add that to even more, but its already being worked on USB, so
> chill and let him be.
>
> Just my 2 cents~~~
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

On 15 April 2010 19:22, Daniel Reimer <
[e-mail]> wrote:
> Good luck in finding hobby programmers who do what you tell em to do. As
> long as you cant pay them, its hard to force them in direction. If they
> loose interest or fun in coding for ROS then we are not just stagnating, we
> are deserted. If you wanna risk this, feel free to. I cant and wont stop
> you.

I didn't say that at all. Please don't put words into my mouth.
Intelligent people are supposed to be able to get together and decide what's
best for the project for the greater good.
What's the point in writing a PCMCIA driver if the operating system it runs
in never gets used?
> And I still think PCMCIA is important and useful right now.
>
> Well, you think VMs are more important than Real HW? You were kidding,
> right?!

Considering devs and testers rely entirely on VM's to develop the OS, then
of course it's more important right now.
If VM's don't work how is anyone supposed to develop the OS? This isn't
1990....
In the long run, of course users want real hardware support, that's obvious,
but we have an alpha OS and we need working VM's to get us to that stage.

Ged.

[James Tabor]

All contributions are welcome regardless when it comes from those that
break stuff. I do not see anyone else sticking their neck out on the
block!

If you are not breaking anything you are not working!!!!!

So to those that bitch the most, when did you break anything?

Locking shit down all the time is not helping anyone!

Instead of writing this, I should be working on ReactOS, So please let
me know when I can start working again, motivate me, I do not get paid
for this, what is my motivation?

[Olaf Siejka]

Usefull indeed, though we should be more strict on what goes into the trunk.
The more code goes there, the longer build takes, also there is a bigger
chance to break trunk with other changes. This is why we should isolate
trunk/apps/tests from other things, then tidy it up and reorganize it. All
code like the one in question could be placed there.

Best regards

2010/4/16 James Tabor [e-mail]
> All contributions are welcome regardless when it comes from those that
> break stuff. I do not see anyone else sticking their neck out on the
> block!
>
> If you are not breaking anything you are not working!!!!!
>
> So to those that bitch the most, when did you break anything?
>
> Locking shit down all the time is not helping anyone!
>
> Instead of writing this, I should be working on ReactOS, So please let
> me know when I can start working again, motivate me, I do not get paid
> for this, what is my motivation?

[Andrew Faulds]

ROSLite?

Sent from my iPod
Andrew Faulds

On 16 Apr 2010, at 10:48, Olaf Siejka [e-mail] wrote:

Usefull indeed, though we should be more strict on what goes into the trunk.
The more code goes there, the longer build takes, also there is a bigger
chance to break trunk with other changes. This is why we should isolate
trunk/apps/tests from other things, then tidy it up and reorganize it. All
code like the one in question could be placed there.

Best regards

2010/4/16 James Tabor [e-mail]
> All contributions are welcome regardless when it comes from those that
> break stuff. I do not see anyone else sticking their neck out on the
> block!
>
> If you are not breaking anything you are not working!!!!!
>
> So to those that bitch the most, when did you break anything?
>
> Locking shit down all the time is not helping anyone!
>
> Instead of writing this, I should be working on ReactOS, So please let
> me know when I can start working again, motivate me, I do not get paid
> for this, what is my motivation?

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[breakoutbox]

Andrew Faulds schrieb:
> ROSLite?

If then ReactOS runs more stable - do it !

[Olaf Siejka]

Too soon for more than one trunk. I only concur of what devs say, trunk has
to be revised and possibly - skimmed a bit.

Look, why is atapi still in trunk?? Stuff like this take up precious
buildtime and space.

2010/4/16 breakoutbox [e-mail]
> Andrew Faulds schrieb:
> > ROSLite?
>
> If then ReactOS runs more stable - do it !
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

what about having 2 branches (at least)?

the "stable" one and the "unstable" one...

On Fri, Apr 16, 2010 at 11:48 AM, Olaf Siejka [e-mail] wrote:
> Usefull indeed, though we should be more strict on what goes into the
> trunk. The more code goes there, the longer build takes, also there is a
> bigger chance to break trunk with other changes. This is why we should
> isolate trunk/apps/tests from other things, then tidy it up and reorganize
> it. All code like the one in question could be placed there.
>
> Best regards
>
> 2010/4/16 James Tabor [e-mail]
>
> All contributions are welcome regardless when it comes from those that
> > break stuff. I do not see anyone else sticking their neck out on the
> > block!
> >
> > If you are not breaking anything you are not working!!!!!
> >
> > So to those that bitch the most, when did you break anything?
> >
> > Locking shit down all the time is not helping anyone!
> >
> > Instead of writing this, I should be working on ReactOS, So please let
> > me know when I can start working again, motivate me, I do not get paid
> > for this, what is my motivation?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

This would be needed when we have a minimally usable OS, and creating  
branches *before* that happens doesn't make sense. Otherwise  
maintaing efforts are going to eat needed manpower.

On Apr 16, 2010, at 2:38 PM, Javier Agustìn Fernàndez Arroyo wrote:
> what about having 2 branches (at least)?
>
> the "stable" one and the "unstable" one...
>
> On Fri, Apr 16, 2010 at 11:48 AM, Olaf Siejka [e-mail]  
> wrote:
> Usefull indeed, though we should be more strict on what goes into  
> the trunk. The more code goes there, the longer build takes, also  
> there is a bigger chance to break trunk with other changes. This is  
> why we should isolate trunk/apps/tests from other things, then tidy  
> it up and reorganize it. All code like the one in question could be  
> placed there.
>
> Best regards
>
> 2010/4/16 James Tabor [e-mail]
>
> All contributions are welcome regardless when it comes from those that
> break stuff. I do not see anyone else sticking their neck out on the
> block!
>
> If you are not breaking anything you are not working!!!!!
>
> So to those that bitch the most, when did you break anything?
>
> Locking shit down all the time is not helping anyone!
>
> Instead of writing this, I should be working on ReactOS, So please let
> me know when I can start working again, motivate me, I do not get paid
> for this, what is my motivation?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Andrew Faulds wrote:
> Yes. We need a "Linus Torvalds" for ReactOS. If it worked for Linux, it'll
> work for ReactOS.

No. A "trunk manager" selecting what he likes won't work for reactos,
because we just don't have enough devs for any kind of cherry picking.
We need to take what we get. It would also slow down development as
people are forced to wait for a single person.

Currently most devs don't even seem to like the idea of branches. It
sounds like being banned from trunk. First that has to change.
Ideally noone would work in trunk. Especially nasty quick hackfixes
regressing the shit out of reactos and half ready drivers should really
stay out of trunk.

"But if I work in a branch noone will test it then"...
Seriously, the "Commit and force everyone else to fix it" mentality is
not how we can work any longer. We have testers. And they are very well
able to test branches and they are able to track down guilty revisions
in a branch as well. Cases where something works perfectly fine in the
branch and then mysteriously starts failing when being comitted to trunk
should be very very rare.

Currently, when someone detects a regression, he says "hmm. xyz doesn't
work" in #reactos-dev. Some days later it gets confirmed by someone
else. Then someone writes a bugreport. That's it. But we can't continue
as if nothing happened.

What we need is more responsibility.
IMHO we need a "zero-regressions" policy for trunk. Yes, even the best
tested code can cause regressions, but if something regressed, then the
guilty commit needs to be detected asap and either fixed or reverted.
Accumulating regressions will always lead to discouragement and slowed
down development. Of course there are cases when a fix might judge a
smaller regression. These can be announced / discussed before comitting
to trunk.

My 2 cents,
Timo

PS: I'm for a feature freeze until all regerssions are solved