On Sun, Mar 06, 2005 at 06:44:51AM -0300, Marcelo Tosatti wrote:
> > - It must fix a problem that causes a build error (but not for things
> >marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
>
> "and breakage of previously working functionality" ?
I'd vote to include this
On Sun, 2005-03-06 at 15:10 -0500, Adam Kropelin wrote:
> Andres Salomon <[EMAIL PROTECTED]> wrote:
> > On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
> > > On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> > >> - It must fix a real bug that bothers people (not a, "This could
On Sun, 2005-03-06 at 23:50 -0800, Paul Jackson wrote:
> Andres wrote:
> > An obvious fix is an obvious fix.
>
> Perhaps in theory. But in practice, any fix bears some risk.
>
Of course; no one's arguing that (things that depend on broken behavior,
corner cases, etc). In practice, however; an
Andres wrote:
> An obvious fix is an obvious fix.
Perhaps in theory. But in practice, any fix bears some risk.
They have nothing against "obvious" fixes. But unless additional
criteria are also met, such fixes are for someone else to apply.
> >> - It can not contain any "trivial" fixes in it
Andres Salomon <[EMAIL PROTECTED]> wrote:
> On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
> > On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> >> - It must fix a real bug that bothers people (not a, "This could be a
> >>problem..." type thing.)
>
> An obvious fix is an o
On Sat, 05 Mar 2005 11:43:05 +0100, Andries Brouwer wrote:
> On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
>
>> Anything else anyone can think of? Any objections to any of these?
>> I based them off of Linus's original list.
>>
>> thanks,
>>
>> greg k-h
>>
>> --
>>
>> Rules on
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> Anything else anyone can think of? Any objections to any of these?
> I based them off of Linus's original list.
>
> thanks,
>
> greg k-h
>
> --
>
> Rules on what kind of patches are accepted, and what ones are not, into
> the "linu
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> Anything else anyone can think of? Any objections to any of these?
Well, Linus's rules regarding signoff are good as well. I'd
suggest, once there is a set of $sucker-evaluators, we could use a good
rule like requiring 5 folks to
On Fri, 4 Mar 2005, Greg KH wrote:
> Anything else anyone can think of? Any objections to any of these?
> I based them off of Linus's original list.
>
How about feature regressions? What made me think of this is the thread
about the 8x0 alsa breakage in 2.6.11. 2.6.10 and 2.6.9 worked well fo
Greg KH wrote:
On Sat, Mar 05, 2005 at 02:59:17PM +0100, Adrian Bunk wrote:
An example that doesn't fit:
A patch of me to remove an unused function was accepted into 2.6.11 .
Today, someone mailed that there's an external GPL'ed module that uses
this function.
A patch to re-add this function as
Greg KH wrote:
On Sat, Mar 05, 2005 at 02:59:17PM +0100, Adrian Bunk wrote:
An example that doesn't fit:
A patch of me to remove an unused function was accepted into 2.6.11 .
Today, someone mailed that there's an external GPL'ed module that uses
this function.
A patch to re-add this function as i
Adam Sampson wrote:
Greg KH <[EMAIL PROTECTED]> writes:
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
So a trivial patch that fixed a data corruption issue wouldn't be
accepted?
That's called a critical pa
On Sat, Mar 05, 2005 at 09:58:00AM +, Adam Sampson wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > - It must fix a problem that causes a build error (but not for things
> >marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
>
> So a trivial patch that fixed a data corrup
On Sat, Mar 05, 2005 at 02:59:17PM +0100, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
>
> > Anything else anyone can think of? Any objections to any of these?
> > I based them off of Linus's original list.
>
> Are these 100% fixed rules or just guidelines you us
On Sat, Mar 05, 2005 at 11:43:05AM +0100, Andries Brouwer wrote:
> On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> Objections - no. Anything else - yes.
> I would like the requirement: "It must be obviously correct".
Doh, forgot that one, I'll go add it.
thanks,
greg k-h
-
To unsubscr
On Sat, Mar 05, 2005 at 12:57:42AM -0500, Shawn Starr wrote:
> How does this fit into Rusty's trivial patch bot? This process will fold
> that
> into a formal method now?
The last rule explicitly states that the linux-release tree will _not_
be accepting patches that are acceptable to the trivi
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> Anything else anyone can think of? Any objections to any of these?
> I based them off of Linus's original list.
Are these 100% fixed rules or just guidelines you use?
An example that doesn't fit:
A patch of me to remove an unused funct
On Saturday 05 March 2005 00:08, Ian Pilcher wrote:
> Greg KH wrote:
> > Anything else anyone can think of? Any objections to any of these?
> > I based them off of Linus's original list.
>
> Must already be in Linus tree (i.e. 2.6.X+1)?
How about must be logicily fixed in the Linus tree - Linus
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote:
> Anything else anyone can think of? Any objections to any of these?
> I based them off of Linus's original list.
>
> thanks,
>
> greg k-h
>
> --
>
> Rules on what kind of patches are accepted, and what ones are not, into
> the "lin
Greg KH <[EMAIL PROTECTED]> writes:
> - It must fix a problem that causes a build error (but not for things
>marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
So a trivial patch that fixed a data corruption issue wouldn't be
accepted?
--
Adam Sampson <[EMAIL PROTECTED]>
On Fri, 04 Mar 2005 23:08:55 CST, Ian Pilcher said:
> Greg KH wrote:
> > Anything else anyone can think of? Any objections to any of these?
> > I based them off of Linus's original list.
>
> Must already be in Linus tree (i.e. 2.6.X+1)?
Not workable. There's a high probability that we hit a bug
patches either.
List: linux-kernel
Subject: [RFQ] Rules for accepting patches into the linux-releases tree
From: Greg KH
Date: 2005-03-04 22:21:46
Message-ID: <20050304222146.GA1686 () kroah ! com>
[Download message RAW]
Anything else anyone can think of? Any objections to
How does this fit into Rusty's trivial patch bot? This process will fold that
into a formal method now?
Shawn.
> List: linux-kernel
> Subject:[RFQ] Rules for accepting patches into the linux-releases tree
> From: Greg KH
> Date: 2005-03-04 22:2
On Fri, 2005-03-04 at 23:08 -0600, Ian Pilcher wrote:
> Greg KH wrote:
> > Anything else anyone can think of? Any objections to any of these?
> > I based them off of Linus's original list.
>
> Must already be in Linus tree (i.e. 2.6.X+1)?
No, it's cleaner in bitkeeper terms for the patches to be
Greg KH wrote:
Anything else anyone can think of? Any objections to any of these?
I based them off of Linus's original list.
Must already be in Linus tree (i.e. 2.6.X+1)?
--
Ian Pilcher
Anything else anyone can think of? Any objections to any of these?
I based them off of Linus's original list.
thanks,
greg k-h
--
Rules on what kind of patches are accepted, and what ones are not, into
the "linux-release" tree.
- It can not bigger than 100 lines, with context.
- It must
26 matches
Mail list logo
