[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

[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 <ajfweb at googlemail.com> 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 <peter.millerchip at gmail.com> 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 <elhoir at gmail.com>:
>> > bad one, i guess
>> > that would slow down development a lot
>> >
>> > On Thu, Apr 15, 2010 at 11:14 AM, Peter Millerchip
>> > <peter.millerchip at 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?
>> >>
>> >> 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
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> --
> Andrew Faulds (andrewros)
> http://ajf.me/
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>