public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Corry <corryk@us.ibm.com>
To: Greg KH <greg@kroah.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	evms-devel@lists.sourceforge.net
Subject: Re: EVMS Submission for 2.5
Date: Thu, 3 Oct 2002 07:13:11 -0500	[thread overview]
Message-ID: <02100307131100.05904@boiler> (raw)
In-Reply-To: <20021002224343.GB16453@kroah.com>

On Wednesday 02 October 2002 17:43, Greg KH wrote:
> Some comments on the code:
> 	- you might want to post a patch with the whole evms portion of
> 	  the code, for those people without BitKeeper to see.
> 	- The #ifdef EVMS_DEBUG lines are still in AIXlvm_vge.c, I
> 	  thought you said you were going to fix this file up?
> 	- The OS2 and S390 files don't look like they have been fixed,
> 	  like you said you would before submission.

I have been working on these, and should have them done very soon. At the 
very least, I expect to get OS2 done today. I will let you know as soon as it 
is ready.

> 	- evms_ecr.h and evms_linear.h have a lot of unneeded typedefs.

For the time being, I have removed these files from the tree. As I mentioned 
the other day, they are a long way from providing any useful clustering 
functionality.

> 	- the md code duplication has not been addressed, as you said it
> 	  would be.

We will be addressing this. Unfortunately, I don't see this as being a 
simple, overnight fix. Finding a way to consolidate the common code may take 
some time.

> 	- the BK repository contains a _lot_ of past history and merges
> 	  that are probably unnecessary to have.  A few, small
> 	  changesets are nicer to look at :)

No offense meant, Greg, but that seems a bit contradictory. The way I see it, 
I can maintain our Bitkeeper tree in one of two ways.

1) Try to mirror the usage of our CVS tree. This means that each file or 
small group of files that gets checked into CVS also gets checked into 
Bitkeeper, and the comment logs can stay closely in sync. Doing this produces 
a _lot_ of _small_ changesets, but each one is fairly easy to read and 
understand. However, as you mentioned, it does produce a very long history.

2) Just do a periodic sync with the current CVS tree, maybe every three days 
or so. This will obviously produce far less history, but each changeset may 
be quite large, and thus harder to read and understand, especially since the 
comments will likely be something along the lines of "sync'ing with CVS".

> Why don't you propose a small evms patch that adds the core
> functionality, and worry about getting all of the plugins and other
> assorted stuff in later?  You will probably get more constructive
> comments, as wading through a patch 37956 lines long is a bit difficult.

This is fine with me. I've been maintaining our Bitkeeper tree because I've 
been told by numerous people that it is the easiest way to get new code 
accepted into the kernel. If it turns out that this isn't actually the best 
approach, I'll be more than happy to just send patches. Dual-maintaining CVS 
and Bitkeeper trees is certainly no small task.

So, I will send in a few patches that introduce just the core code so 
everyone can get a good look. There will be four files coming: evms.c, 
evms.h, evms_ioctl.h, and evms_biosplit.h.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

  reply	other threads:[~2002-10-03 12:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-02 21:33 EVMS Submission for 2.5 Kevin Corry
2002-10-02 22:14 ` Alexander Viro
2002-10-02 22:03   ` Kevin Corry
2002-10-02 23:02     ` Alexander Viro
2002-10-03 13:04       ` Kevin Corry
2002-10-03 14:51         ` Alexander Viro
2002-10-03 14:53           ` Kevin Corry
2002-10-03 15:37             ` Alexander Viro
2002-10-03 16:13           ` Greg KH
2002-10-03 16:21             ` Alexander Viro
2002-10-03 16:30               ` Greg KH
2002-10-03 17:00                 ` David Lang
2002-10-03 17:27                   ` Greg KH
2002-10-03 19:52                 ` [Evms-devel] " Oliver Neukum
2002-10-03 21:37                   ` Greg KH
2002-10-03 21:02                     ` Oliver Neukum
2002-10-03 22:56                       ` Greg KH
2002-10-03 23:03                         ` Alexander Viro
2002-10-04  8:07                         ` Oliver Neukum
2002-10-05  0:06                           ` Greg KH
2002-10-03 16:55           ` Patrick Mochel
2002-10-03 19:24           ` Linus Torvalds
2002-10-02 22:27   ` Shawn
2002-10-02 22:19 ` Shawn
2002-10-02 22:43 ` Greg KH
2002-10-03 12:13   ` Kevin Corry [this message]
2002-10-03 16:23     ` Greg KH
2002-10-03 16:51       ` Linus Torvalds
2002-10-03 21:56   ` Kevin Corry
2002-10-03 23:07     ` Greg KH
2002-10-04  0:39       ` Kevin Corry
2002-10-04 13:06         ` Alan Cox
2002-10-04 13:07           ` [Evms-devel] " Kevin Corry
2002-10-04 17:29             ` Kai Henningsen
2002-10-03 14:32 ` Christoph Hellwig
2002-10-03 14:59   ` [Evms-devel] " Michael Clark
2002-10-03 15:08     ` Christoph Hellwig
2002-10-03 15:03   ` Shawn
2002-10-03 15:31     ` Christoph Hellwig
2002-10-03 15:41       ` [Evms-devel] " Mike Tran

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=02100307131100.05904@boiler \
    --to=corryk@us.ibm.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox