Messages in this thread |  | | Date | Mon, 4 Sep 2000 23:02:27 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: [patch] Updated bfs to use new mark_buffers_dirty interface |
| |
Rasmus,
I think it is worth it to clarify this even if you already understood it yourself - other readers of linux-kernel may find it useful (and those who find it too obvious will forgive me).
The concept of Linux subsystem maintainer doesn't mean that _any_ changes to his subsystem should go through him/her. For example, I maintain BFS filesystem but Linux VFS has undergone a huge amount of changes (well, a rewrite, or even several rewrites) by Al Viro who is always kind enough to make sure his changes don't break any filesystems. So, when he changes VFS he simply updates BFS (and all other filesystems) without bothering me (and all other maintainers) about it. Of course, maintainers ought to monitor his changes (and they do) and voice their opinions if they believe he breaks anything (he never does :).
So, this mark_buffer_dirty() change is a good example of the situation where you should _not_ bother maintainers but produce a big patch and send to Linus (if 100% confident) or to linux-kernel (if 99% confident).
Regards, Tigran
On Mon, 4 Sep 2000, Tigran Aivazian wrote:
> On Mon, 4 Sep 2000, Rasmus Andersen wrote: > > > Hi. > > > > I have changed the interface to mark_buffer_dirty (as per your > > suggestion to Arnaldo Carvalho de Melo). This impacts bfs as per > > the following patch. > > > > Rasmus, thanks of course, but this idea _only_ makes sense if you produce > a big patch that includes _all_ filesystems and the actual VFS interface > to them. Doing individual filesystems, in this case, is no use at all - > your patches cannot be applied gradually. > > To be more blatant, the patch you sent me "breaks" bfs because it won't > compile anymore... see what I am saying? > > Regards, > Tigran > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |