Marcus Brinkmann wrote:
It is true that the email notifications are mostly useless, and I
usually only use them as an indication that something changed.
If everyone agrees they are useless, we can disable them. It's simple
enough to do. Or we could go and help the savannah people make them
useful
If everyone agrees they are useless, we can disable them.
I don't agree with disabling them just like that, what about creating
a mailing list just for the Savannah notifications that is read only?
Kinda like commit-hurd.
Then those who want can read it, and those that don't can ignore them.
At Fri, 07 Jan 2005 14:35:25 +,
Neal H. Walfield wrote:
> You might have a good point if the maintainers supported using
> savannah. This is simple not the case. Roland, for instance, has
> recently said [1] that he mostly ignores the messages from the
> savannah patch manager as it is too di
Barry deFreese schrieb:
If a release is useful, I don't think there is any reason to wait for any
particular fixes or features beforehand. Obviously the status quo is
years
better than 0.2 (literally) already. I don't see any harm in doing 0.3
tomorrow and 0.4 next week if worthwhile fixes/featu
To the maintainers and large contributors: Would using another bug
database system that is equally usable to the group be worth
considering?
IMHO, yes. If you would like to work on this please contact
[EMAIL PROTECTED]
___
Bug-hurd mailing li
On Fri, 2005-01-07 at 10:25, Alfred M. Szmidt wrote:
>I don't ask you to change the way you work, but to consider
>participating (at times) in something you reject to participate in.
>And nothing of this is for the sake of Savannah, but for the sake of
>this project.
>
> My bug rep
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
> "Neal H. Walfield" <[EMAIL PROTECTED]> wrote,
>
>You might have a good point if the maintainers supported using
>savannah. This is simple not the case.
>
> But the stated reason that [EMAIL PROTECTED] will not send in bug
> reports is t
But the stated reason that [EMAIL PROTECTED] will not send in bug
reports is that the maintainers insist on using this particular
mechanism.
I have a name you know.
the Hurd effort requires that bug reports involve a particular
interface.
And that interface is [EMAIL PROTECTED]
"Neal H. Walfield" <[EMAIL PROTECTED]> wrote,
You might have a good point if the maintainers supported using
savannah. This is simple not the case.
But the stated reason that [EMAIL PROTECTED] will not send in bug
reports is that the maintainers insist on using this particular
mechanism.
Barry deFreese schrieb:
If a release is useful, I don't think there is any reason to wait for any
particular fixes or features beforehand. Obviously the status quo is
years
better than 0.2 (literally) already. I don't see any harm in doing 0.3
tomorrow and 0.4 next week if worthwhile fixes/featu
You might try using the bug tracker before trying to tell people what
they should use. If you consider it so important that you must preach
to me, then you might do something better and help the Savannah
project with improving the bug tracker. Cause, if it is improved just
a bit then I will use i
I don't ask you to change the way you work, but to consider
participating (at times) in something you reject to participate in.
And nothing of this is for the sake of Savannah, but for the sake of
this project.
My bug reports have a better track record of getting fixed then any of
the
At Fri, 7 Jan 2005 13:33:05 + (UTC),
Robert J. Chassell wrote:
>
> The key point is that you are seeking help.
>
>I'm not seeking help.
>
> Right. You are the person offering help: to report bugs, but not the
> way they are wanted. The `you' was directed to people already in the
At Fri, 07 Jan 2005 00:09:56 +0100,
Alfred M Szmidt wrote:
> operation of cut and pasting between Emacs and Lynx. I won't change
> the way how I work for the sake of Savannah.
I don't ask you to change the way you work, but to consider
participating (at times) in something you reject to participa
The key point is that you are seeking help.
I'm not seeking help.
Right. You are the person offering help: to report bugs, but not the
way they are wanted. The `you' was directed to people already in the
project.
Perhaps your offer should be rejected on account the pay for accepting
y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Danilo Segan wrote:
| Today at 9:14, Ognyan Kulev wrote:
|
|
|>>4) could it be run inside a virtual machine (im thinking of vmware)?
|>>Has anybody tried it?
|>
|>Yes, some people us it with success. qemu is faster but less stable.
|
|
| Actually, I re
Today at 9:14, Ognyan Kulev wrote:
>> 4) could it be run inside a virtual machine (im thinking of vmware)?
>> Has anybody tried it?
>
> Yes, some people us it with success. qemu is faster but less stable.
Actually, I remember reports of it running in Bochs â a free software
x86 emulator, where i
The more I think about it, the less I think we "need" a new
release.
Nobody needs a release, really. You can always point to a date in
CVS.
We we need is to spread the word. A good deal of the information
available is outdated, many of the websites are not up to date,
there is ve
> Besides, i havent found any useful docs about L4, what is it? a
> substitute for arch? who is developing it? Now i have my exams
> but from february ill have some free time to work on this and i
> have some questions.
I think it's good question for our FAQ.
Feel free to post a up
Daniel Godás wrote:
Ok, after the presentation. I have taken a look at the archives and
the dev-hurd list archives are very outdated, why? why is this topic
beeing discussed in this list and not there?
You probably mean hurd-devel. It's only for core developers.
The two active core developers (Ma
Hi,
Im new here and some days ago i wanted to give my opinion on making a
release (maybe the point of view of someone from outside could be
useful) but i hit the reply button instead of reply all (oops).
Im reading some docs and im trying to learn how the HURD works so i
can help. Im a telecommun
Roland McGrath wrote:
Roland, what do you think?
Whatever Marcus likes is fine with me, basically. I don't know what
benefit people find from a GNU tarball release, since everyone actually
interested in the Hurd is directed either to Debian packages (for using) or
to the CVS sources (for hack
On Thu, 2005-01-06 at 12:52 +0100, Alfred M. Szmidt wrote:
>Releasing something that's buggy where the developers don't realize
>it, makes it aggravating.
>
> This is impossible to achive, no release is bug free. And all
> maintainers that make releases know that what they release contain
> Roland, what do you think?
Whatever Marcus likes is fine with me, basically. I don't know what
benefit people find from a GNU tarball release, since everyone actually
interested in the Hurd is directed either to Debian packages (for using) or
to the CVS sources (for hacking). If the motivation
If you exclude yourself from this resource we all lose.
Too bad.
The key point is that you are seeking help. If the help refuses, even
for what you think is a good reason, then you are right, we all lose.
So it is your moral responsibility to consider whether our loss is
bigger or less t
The key point is that you are seeking help.
I'm not seeking help.
So it is your moral responsibility to consider whether our loss is
bigger or less than the trouble that [EMAIL PROTECTED] creates.
My "moral" responsibility is to report bugs, and I do exactly that.
Your "moral" responsib
> All I am asking is to be able to send bug reports via mail into
> the database, not for the perfect bug tracking system.
It is a reasonable feature to want, but primarily for the user, not
for the developers.
I beg to differ, if you cannot comment, or even send a patch for a bug
rep
At Thu, 06 Jan 2005 21:05:47 +0100,
Alfred M Szmidt wrote:
> All I am asking is to be able to send bug reports via mail into the
> database, not for the perfect bug tracking system.
It is a reasonable feature to want, but primarily for the user, not
for the developers.
As much as I hate to regist
It wouldn't be easy to diddle all those customizable fields over
email.
Point there.
I know where you are coming from, but the perfect bug tracking
system that fits everybody doesn't exist. Everybody has to chip in
and compromise a bit, and that's what I do at least.
All I am ask
At Thu, 06 Jan 2005 16:45:01 +0100,
Alfred M Szmidt wrote:
>
>I really hope people will submit bug reports on savannah so I can fix
>some of them when I have the time.
>
> Problem with the the darn bug tracker is that you can't report them
> via email.
It wouldn't be easy to diddle all t
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Just to be really clear: I did not suggest a 0.3 release.
>
>Was that a mistake, or are you suggesting a 1.0 release?
>
> I think Marco was just suggesting that a relase should be made, and
> what it is called is not important.
Right, I wa
> Just to be really clear: I did not suggest a 0.3 release.
Was that a mistake, or are you suggesting a 1.0 release?
I think Marco was just suggesting that a relase should be made, and
what it is called is not important.
___
Bug-hurd mailing lis
Marco Gerards wrote:
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
I think it might also be nice to create a "punch list" of known bugs
or missing features that people think are essential for a 1.0
release.
Just to be really clear: I did not suggest a 0.3 release.
Was that a mistake, or are yo
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>- console on startup
>
> Not a problem with the Hurd, up to the system maintainers.
It is. What I meant here is making sure all servers, like ext2, use
the Hurd console for their output. Having this is, as far as I am
concerned, a requirement
I really hope people will submit bug reports on savannah so I can fix
some of them when I have the time.
Problem with the the darn bug tracker is that you can't report them
via email. That is why I don't bother with Savannah.
___
Bug-hurd mailin
Version 0.4:
- console on startup
Not a problem with the Hurd, up to the system maintainers.
- fix the gnumach serial driver
Not a problem with the Hurd.
What do you think? I hope it is not too silly? ;)
Good idea, but that doesn't mean that you're not silly.
__
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Barry deFreese <[EMAIL PROTECTED]> writes:
>
>> Well might as well throw in my 2 cents. I agree with the majority of
>> the sentiments expressed here. If we can verify that the ext2fs
>> limitation is truly fixed, I think that would be a great th
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>At lease with a bug list, it cuts down on the confusion. With a bug
>list, people know what to expect.
>
> Known bugs should be fixed before a release, then when people find
> bugs after the release, they report them, and they get fixed. And
Oh, I had the feeling a program like dhclient still needed to be
written/ported to use the new support. If not, that's even better.
:-)
dhclient works on GNU/Hurd, I need to write the scripts for it that
are "clean", Marco used some kind of hacked thing I belive.
__
Alfred M. Szmidt wrote:
- mozilla and/or mozilla firefox should run.
- gnome and/or kde should run.
- probably OpenOffice.org as well.
... are not related to the Hurd.
- decent network support (including dhcp).
We have DHCP now it seems,
Oh, I had the feeling a program like dhclient sti
- mozilla and/or mozilla firefox should run.
- gnome and/or kde should run.
- probably OpenOffice.org as well.
... are not related to the Hurd.
- decent network support (including dhcp).
We have DHCP now it seems, don't know what "decent network support".
__
Alfred M. Szmidt wrote:
I think it might also be nice to create a "punch list" of known
bugs or missing features that people think are essential for a 1.0
release.
And/Or for the next release. Features that would take time to
implement (libchannel?) could wait a bit, but bug fixes should
Releasing something that's buggy where the developers don't realize
it, makes it aggravating.
This is impossible to achive, no release is bug free. And all
maintainers that make releases know that what they release contains
bugs, somewhere.
At lease with a bug list, it cuts down on the
I think it might also be nice to create a "punch list" of known
bugs or missing features that people think are essential for a 1.0
release.
And/Or for the next release. Features that would take time to
implement (libchannel?) could wait a bit, but bug fixes should be put
into the next re
Barry deFreese <[EMAIL PROTECTED]> writes:
> Well might as well throw in my 2 cents. I agree with the majority of
> the sentiments expressed here. If we can verify that the ext2fs
> limitation is truly fixed, I think that would be a great thing. Is
> has been a big stickler for a lot of people.
Well might as well throw in my 2 cents. I agree with the majority of
the sentiments expressed here. If we can verify that the ext2fs
limitation is truly fixed, I think that would be a great thing. Is has
been a big stickler for a lot of people.
I also have to say, that after installing K7 at
I think that a list of user visible bugs is a good idea, not compiling a
list of what works, and what doesn't helps more people than just
newbies. Releasing something that's buggy where the developers don't
realize it, makes it aggravating. At lease with a bug list, it cuts down
on the confusion. W
Ognyan Kulev <[EMAIL PROTECTED]> writes:
> Marco Gerards wrote:
> > Anyway, I hope to start a discussion with this email. It would be
> > nice if the Hurd maintainers would make it clear what needs to be done
> > before the Hurd 0.3 can be released or if they just release it.
>
> Yes, I think th
Bas Wijnen <[EMAIL PROTECTED]> wrote:
Alfred M. Szmidt wrote:> If someone is Hurd newbie and (s)he tries to use fakeroot for> building Debian packages, what do you think that (s)he'll think> about the Hurd?> > What will the newbie think if she/head finds a totally obscure bug> that eats the file-
Alfred M. Szmidt wrote:
If someone is Hurd newbie and (s)he tries to use fakeroot for
building Debian packages, what do you think that (s)he'll think
about the Hurd?
What will the newbie think if she/head finds a totally obscure bug
that eats the file-system, or any other horrible thing?
If someone is Hurd newbie and (s)he tries to use fakeroot for
building Debian packages, what do you think that (s)he'll think
about the Hurd?
What will the newbie think if she/head finds a totally obscure bug
that eats the file-system, or any other horrible thing? I think that
you don't
Alfred M. Szmidt wrote:
Buggy software gives bad impression and I think we should at least
mark the bad things.
All software is buggy, and we aren't talking about a 1.0 release, just
0.3 anyway. So I don't think this is a problem.
It's mostly psychological problem. If someone is Hurd newbie
Buggy software gives bad impression and I think we should at least
mark the bad things.
All software is buggy, and we aren't talking about a 1.0 release, just
0.3 anyway. So I don't think this is a problem.
___
Bug-hurd mailing list
Bug-hurd@gnu
Marco Gerards wrote:
Anyway, I hope to start a discussion with this email. It would be
nice if the Hurd maintainers would make it clear what needs to be done
before the Hurd 0.3 can be released or if they just release it.
Yes, I think the most important thing now is to clearly set what are the
re
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Ogi's ext2fs patches should be included before we make a release, it
> is the most "user visible" change after console-client.
We could even make a release now and another one when Ogi's patches
are applied. But that is not up to me.
Thanks,
Marc
Ogi's ext2fs patches should be included before we make a release, it
is the most "user visible" change after console-client.
Other then that I can say that I'd like to see a release this year.
Alot of things have changed since 0.2, so a release is a good thing.
If we make a release, then we should
Hi,
When will the Hurd 0.3 be released? IMHO it would be nice to have a
release, only to have something on hurd.gnu.org to show the project is
not completely dead. We can use some publicity and besides that, it
seems a bit strange to me that there was no release for about 6 years
or so.
Anyway,
57 matches
Mail list logo
