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 tim
On 15 April 2010 19:22, Daniel Reimer <
daniel.rei...@stud-mail.uni-wuerzburg.de> 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 j
hm?
On Thu, Apr 15, 2010 at 8:33 PM, Samuel serapion wrote:
> Javier this isn't funny. ReactOS is serious business.
>
>
> 2010/4/15 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, Ap
Test bot is broken, I usually "tracked" regressions that way... please fix.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Javier this isn't funny. ReactOS is serious business.
2010/4/15 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 wrote:
>
>> Yes, but we get "donation
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
Gabriel ilardi schrieb:
Explorer has all kind of visual glitches you can imagine and even more.
keyboard layout issues: it's language dependent when it shouldn't be,
changing keyboard layout doesn't work,
kb layout tools dont' work, wrong keyboard layout in cmd see 3317, 2132,
2133, 2178, 2952,
Great work, thank you very much! That's exactly what I was speaking
about yesterday.
I'm considering freezing trunk to only allow fixes for these
regression. If noone objects, this is going to become reality tonight.
WBR,
Aleksey.
On Apr 15, 2010, at 5:14 PM, Gabriel ilardi wrote:
Hi te
Looks like Gabriel did a bugzilla attack too.
I'd like to add some comments: i've also been working the bug list of a
humble 600 items up and down, mainly addressing the easy visual and
configuration issues. See http://cia.vc/stats/author/gschneider.
I've skipped generelly skipped big feature enh
I know about this one! It was worse before and I removed the routine
due to the kernel changes and added it back when I thought it was
fixed. ATM just type "cont" at the debug prompt. I'm not sure how it
is reentering even after removing the DCE from the window. Thread lock
should have catch it and
Hi team,
I don't know why, but it seems that bugzilla and ros-bugs is being ignored,
except for some exceptions where I've seen regressions fixed lately.
IMHO it's extremely important the perception people have about us when they
test ros, if ros improved overall but that's not noticeable to t
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 wou
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: ros-dev-boun...@reactos.org
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... Won
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 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 t
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 enou
But wait with Linux doesn't it work because there's one person ultimately
controlling it?
On 15 April 2010 10:37, Peter Millerchip 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 g
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 wrote:
> Yes, but we get "donations" on all sorts of unnecessary things.
> We really need "donations" in *useful areas* like, say, USB.
>
>
> On
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 ;
bad one, i guess
that would slow down development a lot
On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip <
peter.millerc...@gmail.com> 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?
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 wrote:
> 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
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
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
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
> ReactOS has PCMCIA support before USB
> lol :)
>
>
> On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin wrote:
>
>> I fully agree with Ged. I know it's fun
ReactOS has PCMCIA support before USB
lol :)
On Thu, Apr 15, 2010 at 10:46 AM, Aleksey Bragin 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
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
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 pe
27 matches
Mail list logo
