"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
That's why we keep archives of such things and use bug-tracking
software.
You haven't looked at the archives, or used the bug-tracking software
that we use.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
>Patches do not "gather dust" and there is no particular urgency in
>these cases (at least, no reason for urgency has been explained).
>
> When the patch checkers themselfs forget about the patches that have
> been checked and recheck, then t
Just to make it very clear, these patches are not approved yet.
I think that was already quite clear.
Patches do not "gather dust" and there is no particular urgency in
these cases (at least, no reason for urgency has been explained).
When the patch checkers themselfs forget about the p
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:
> I will commit the following three patches in 4 days to
> gnumach-1-branch. I will also take over gnumach-1-branch after those
> four days (and apply the same rules as for ams-branch in the Hurd
> repo). Unless someone screams loudly in my ear...
"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
28 matches
Mail list logo
