Thread (10 messages) 10 messages, 8 authors, 2000-08-05

Re: Getting things in... Was: Re: shifts on 64bit ints

flat view

From: Takashi Oe <hidden>
Date: 2000-08-04 19:44:26

On Fri, 4 Aug 2000, Hendricks, Kevin wrote:
quoted
I'm not really against the web site idea, but it's just that there won't
be too many people submitting patches in the first place to warrent the
extra administrative burden on developers with write access to BK, I would
think.
I don't agree.  A separate website is important.  I don't work on the kernel
directly but I have submitted patches here and there and have run into problems
when testing/debugging the JDK that are kernel issues.
Ok, on a second thought, I feel a patch repository is a good idea for
users.  I was originally not too excited about the idea because people who
actually make the final decisions like Cort or Paul haven't said anything,
and I'm not really positive that they can spend time on dealing with the
patches accumulated in the repository in timely manner.  Unless we have
their blessing, the repository won't work for many of the patches, and
we'll have to default to current method of non-method.  [Well, at least
Ben is willing, so I'm sure the repository will work for pmac specific
patches, actually.]  However, the repository will be good for users who
compile kernels themselves or distribution makers.  They can search for
fixes for specific problems they are facing, and we can point users to
look at the repository for patches.
I don't want write access to any tree, but I do need to see what patches are
going in, what changed, the status of my own patches, etc.

Also, I think we could easily modify any of the simple bugdatabase programs like
bugzilla to do exactly what we want (instead of calling them bugs, call them
patches, instead of fixed, call them accepted, etc)  You could also create
categories so that driver patches are separate from other patches easily with
this type of software.
I agree.  It should be fairly easy to set up.
We are getting more and more people contributing to the kernel process
I feel it's not many more than ten at any given time, if we only count
kernel hackers without the write access who submit patches occasionally or
regularly.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help