"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>I can trust someone to follow agreed rules and not to be malicious.
>That's what it takes for Tier Two. But that's a far cry from
>trusting them to be technically competent, not make certain kinds
>of mistakes, and the like.
>
> If
I can trust someone to follow agreed rules and not to be malicious.
That's what it takes for Tier Two. But that's a far cry from
trusting them to be technically competent, not make certain kinds
of mistakes, and the like.
If a person cannot make a decision, they should ask. That is t
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> I atleast don't see any need for a specific branch right now, I wanted
> ams-branch to have a generic name (devel-branch), but Roland disliked
> that. In either case, I consider it generic.
I dislike the name "devel-branch" because it isn't speci
If you want to suggest the creation of a specific branch for a
specific purpose, I'm all for it.
I atleast don't see any need for a specific branch right now, I wanted
ams-branch to have a generic name (devel-branch), but Roland disliked
that. In either case, I consider it generic.
>
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> I really dislike having a bunch of branches for each and every person.
> Either have a generic branch for tier twos (like ams-branch), or have
> a branch based on a major feature that is being worked on.
If you want to suggest the creation of a sp
Tier Three: Anyone in the world, who is free to submit patches for
consideration.
Tier Two: People who have bits to commit to the archive, and can
have their own branches, but should only commit pre-approved
patches to the main trunk.
I really dislike having a bunch of branches for
Currently we are using a three-tiered model for commit access:
Tier Three: Anyone in the world, who is free to submit patches for
consideration.
Tier Two: People who have bits to commit to the archive, and can have
their own branches, but should only commit pre-approved patches to the
main trunk
Marco Gerards <[EMAIL PROTECTED]> writes:
> Only when you have multiple users that want to share a translator and
> when they do not trust each other. At the moment such multi user
> systems are quite rare AFAIK. More common is a system with a single
> user who is also has the root password.
I
Ah, so you are willing to help us sort out which kernel to spend
effort on, to develop the reasons and arguments why we should
prefer that one rather than the other? Great, let's get to it.
Fine, I'll bite the bait. Please hold while I write the mail (will
take a bit of time).
___
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> At Wed, 09 Nov 2005 21:54:52 +0100,
> Marco Gerards wrote:
>>
>> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>>
>> > The active translator problem seems serious to me. Without any
>> > guarantee about the implementation of a service, you can not k
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>But if it is true that we must pick one or the other, then there is
>a task to be done: picking. If you don't want to help solve that
>task, then it's likely to be unsolved. Ok, but I think it's rather
>churlish to declare that a t
But if it is true that we must pick one or the other, then there is
a task to be done: picking. If you don't want to help solve that
task, then it's likely to be unsolved. Ok, but I think it's rather
churlish to declare that a task is extremely important AND refuse
to lift a finger
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> Problem with that is that you don't even know if the code-base
>> will be used, so such factoring will be useless.
>
>Not if it's done well. The point is that if you can make the code
>base suitable well designed, it will become *
> Problem with that is that you don't even know if the code-base
> will be used, so such factoring will be useless.
Not if it's done well. The point is that if you can make the code
base suitable well designed, it will become *portable* and of
course it will be used.
Then it isn't
14 matches
Mail list logo
