From: David Arendt <admin@prnet.org>
To: reiserfs-list@namesys.com
Subject: 2.6.13 merge
Date: Sat, 25 Jun 2005 15:08:00 +0200 [thread overview]
Message-ID: <42BD5730.7050308@prnet.org> (raw)
Hi,
Here my personal opinion of merging:
I would find it very usefull the have reiserfs merged into the main
kernel, but I think the kernel developers should be able to decide how
they want things in. I would propose to continue discussion with kernel
developers in order to determine actually how to proceed. What I would
for the moment find more important would be to bring out patches as soon
as a new kernel version is available. If people know that they find the
new patches immediately, they will surely give reiser4 a try. I think
the main problem actually is that there will be serveral weeks from the
release of a new kernel until the release of the patches. For example in
my case I need to upgrade to 2.6.12 due to usb problems with 2.6.11. So
what are my options actually ? Well probably I will stop using reiser4
and go back to reiser3. Sure, having reiser4 immediately in the kernel
would solve this problem, but so would patches coming out little time
after a new kernel version is released.
Here how I would proceed:
1. (most important I think) release patches only little time after the
kernel is released
2. look together with kernel developers to find a solution that is
pleasant for everyone
Where I think 1. is much more important than 2. I know lots of people
which reason for not using reiserfs is not that it is currently not in
kernel, but because patches need a long time to be available after the
kernel release.
Also please don't get me wrong with this. I am not trying to say that
reiserfs developers don't work hard, but perhaps development priorities
should be changed a bit, as kernel patches being there in time is in my
opinion more important than adding features or changing to be ready for
inclusion in kernel. I really appreciate your hard work and give you
much respect.
Bye,
David Arendt
reply other threads:[~2005-06-25 13:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42BD5730.7050308@prnet.org \
--to=admin@prnet.org \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.