Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>> Anyone can be part of reviewing patches, and discussing design issues.
>> The thing is about getting Tier One people convinced enough to get
>> those patches in.
>
> This is a good argument for increasing the number of Tier One people
> (a problem
> Sorry. I hate to disrupt into this thread, but according to the
> GNU archives, the GNU maintainers for both the Hurd and gnumach
> packages are Marcus Brinkmann and Roland McGrath.
>
> Would be useful if you could manage to get the archives fixed.
No, this is the official status of things.
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>I thought you wanted me to give direction.
>
> With regard to the Hurd, not GNU Mach.
Tough. I get to be the maintainer of *both*.
Sorry. I hate to disrupt into this thread, but according to the
GNU archiv
If you want it to become HEAD, that's a reasonable thing to want,
and we could discuss it.
So lets do that, what are the reasons not to do so? Nobody as far as
I know is willing to maintain what is now in HEAD, there are people
willing to maintain what is now in gnumach-1-branch.
Alfred, Thomas, I don't know if your getting fun of this, but I
think it isn't funny at all. Please keep serious.
I don't consider it funny at all.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Sergio Lopez <[EMAIL PROTECTED]> writes:
> Alfred, Thomas, I don't know if your getting fun of this, but I think it
> isn't funny at all. Please keep serious.
>
> 1.- Although everybody use gnumach-1-branch, HEAD is oskit-branch. This
> maybe wrong, but it's a maintainer's decission.
Right. If w
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>I thought you wanted me to give direction.
>
> With regard to the Hurd, not GNU Mach.
Tough. I get to be the maintainer of *both*.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>To change the purpose of gnumach-1-branch from being a bugfix-only
>branch is to rearrange.
>
> It is a suggestion, and I fail to see why it would be a bad one.
Because it's the "gnumach-1-branch", not the "HEAD" branch.
If you want it to
El lun, 14-11-2005 a las 08:29 -0800, Thomas Bushnell BSG escribió:
> "Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>
> >> The only really good reason for swapping branches is that the
> >> code in right now HEAD is b0rked, not that gnumach-1-branch is
> >> the most cared about.
> >
I thought you wanted me to give direction.
With regard to the Hurd, not GNU Mach.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
To change the purpose of gnumach-1-branch from being a bugfix-only
branch is to rearrange.
It is a suggestion, and I fail to see why it would be a bad one.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> The only really good reason for swapping branches is that the
>> code in right now HEAD is b0rked, not that gnumach-1-branch is
>> the most cared about.
>
>So fix the code in HEAD.
>
> No. I have no interest in any code that uses
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> I don't see the whole fuss about adding features to
>> gnumach-1-branch, oskit-branch got features added while
>> gnumach-1-branch was HEAD.
>
>Perhaps you don't understand what the branch was created for.
>Maybe you should ask
The "code in the gnumach-1-branch" is nearly identical to the "code
in the HEAD branch".
No it isn't, the code in HEAD uses OSKit. I can't call that nearly
identical.
> I don't see the whole fuss about adding features to
> gnumach-1-branch, oskit-branch got features added while
>
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>If the decision is that the code in gnumach-1-branch is what we
>should care most about using and releasing, and that this is the
>code which should be the basis of ongoing development, then it is,
>de facto, HEAD. Which is what you
If the decision is that the code in gnumach-1-branch is what we
should care most about using and releasing, and that this is the
code which should be the basis of ongoing development, then it is,
de facto, HEAD. Which is what you said.
Right. And if the decision is that, then the bug
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> By swapping gnumach-1-branch to HEAD, you are essentially
>> reverting the bug-fix-only rule anyway, kinda. Work would still
>> be done on the code base that is gnumach-1-branch, but not on
>> that branch.
>
>I think you don't
>> So there is no reason not to revert the `bug fixes only'
>> rule for gnumach-1-branch, if there is a tier one who checks
>> patches.
>
>Incorrect; if your reasoning is right (and I want to hear from
>others too) then the thing to do is to swap the HEAD
>
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> So there is no reason not to revert the `bug fixes only' rule for
>> gnumach-1-branch, if there is a tier one who checks patches.
>
>Incorrect; if your reasoning is right (and I want to hear from
>others too) then the thing to do i
El dom, 13-11-2005 a las 21:14 +0100, Alfred M. Szmidt escribió:
>http://lists.gnu.org/archive/html/hurd-devel/2002-05/msg00060.html
>
>Here, Roland clearly states that gnumach-1-branch is only for
>bugfixes.
>
> That was 3 years ago, when OSKit was all the rage. gnumach-1-branch
> i
> So there is no reason not to revert the `bug fixes only' rule for
> gnumach-1-branch, if there is a tier one who checks patches.
Incorrect; if your reasoning is right (and I want to hear from
others too) then the thing to do is to swap the HEAD designation.
By swapping gnumach-1-bra
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> That was 3 years ago, when OSKit was all the rage. gnumach-1-branch
> is far far simpler to maintain, as has been shown by the continues
> efforts to keep it working as it should including bug fixes, new
> drivers, and what not. I don't even thin
http://lists.gnu.org/archive/html/hurd-devel/2002-05/msg00060.html
Here, Roland clearly states that gnumach-1-branch is only for
bugfixes.
That was 3 years ago, when OSKit was all the rage. gnumach-1-branch
is far far simpler to maintain, as has been shown by the continues
efforts to ke
El dom, 13-11-2005 a las 18:00 +0100, Alfred M. Szmidt escribió:
>Well, it sounds like Sergio Lopez would like one; is that correct?
>
> I have no qualms with that, other than it might be hard to get the
> stuff propagated back to gnumach-1-branch/HEAD depending on how
> detailed Sergio is wit
Well, it sounds like Sergio Lopez would like one; is that correct?
I have no qualms with that, other than it might be hard to get the
stuff propagated back to gnumach-1-branch/HEAD depending on how
detailed Sergio is with ChangeLog's, etc etc etc. So I'd rather see
more use of the existing bra
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>This discussion is being silly. There is no _active_ maintainer
>that wants to invest his time working in GNU Mach (and this
>includes reviewing patches, and even more important, discussing
>design issues).
>
> Anyone can be part of
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> There are also two types of patch build ups, one is the checked
>> patches, which is the only kind of patches in my book, and the
>> other of unchecked patches. When I talk about patches gathering
>> dust I'm talking about checked
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>> So there's only one feasible solution; open a new branch for GNU
>> Mach and GNU Hurd, and allow the people _who still want to work
>> on Mach/Hurd_ do their own way.
>
>I was under the impression we already have such a branch whic
This discussion is being silly. There is no _active_ maintainer
that wants to invest his time working in GNU Mach (and this
includes reviewing patches, and even more important, discussing
design issues).
Anyone can be part of reviewing patches, and discussing design
i
This discussion is being silly. There is no _active_ maintainer
that wants to invest his time working in GNU Mach (and this
includes reviewing patches, and even more important, discussing
design issues).
Anyone can be part of reviewing patches, and discussing design issues.
The thing i
> So there's only one feasible solution; open a new branch for GNU
> Mach and GNU Hurd, and allow the people _who still want to work
> on Mach/Hurd_ do their own way.
I was under the impression we already have such a branch which ams
uses.
Only in the hurd module, and no, I don't w
> There are also two types of patch build ups, one is the checked
> patches, which is the only kind of patches in my book, and the
> other of unchecked patches. When I talk about patches gathering
> dust I'm talking about checked patches.
Checked patches are those which already hav
Sergio Lopez <[EMAIL PROTECTED]> writes:
> So there's only one feasible solution; open a new branch for GNU Mach
> and GNU Hurd, and allow the people _who still want to work on Mach/Hurd_
> do their own way.
I was under the impression we already have such a branch which ams
uses.
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> There are also two types of patch build ups, one is the checked
> patches, which is the only kind of patches in my book, and the other
> of unchecked patches. When I talk about patches gathering dust I'm
> talking about checked patches.
Checked p
El dom, 13-11-2005 a las 06:55 -0800, Thomas Bushnell BSG escribió:
> "Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>
> > I might not understand what Tier Two is for, but I'm not suggesting a
> > wiki-style way of development (where anyone can get tier two access).
> > I'm suggesting a middle gr
I think the problem is specifically in a case like this one, where
people who are able to verify patches are not overflowing with free
time. We cannot run the risk of destabilizing patches building up
because nobody had the time to check things that were already
checked in.
I think
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> I might not understand what Tier Two is for, but I'm not suggesting a
> wiki-style way of development (where anyone can get tier two access).
> I'm suggesting a middle ground, where a tier two doesn't need to ask a
> tier one to fix a bug, a compil
We could do development the way a wiki is run.
I might not understand what Tier Two is for, but I'm not suggesting a
wiki-style way of development (where anyone can get tier two access).
I'm suggesting a middle ground, where a tier two doesn't need to ask a
tier one to fix a bug, a compilation
"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
45 matches
Mail list logo
