All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Balister <philip@balister.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1
Date: Wed, 08 Apr 2009 13:38:39 -0400	[thread overview]
Message-ID: <49DCE11F.90903@balister.org> (raw)
In-Reply-To: <d2b9ea600904080952g656823dby8c15a46b425f76c6@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

Esben Haabendal wrote:
> On Wed, Apr 8, 2009 at 4:26 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> On 08-04-09 16:16, Esben Haabendal wrote:
>>
>>> Then, please someone apply this to .dev.  But then how are we supposed
>>> to remember which patches should also be moved to stable, and when?
>> If you want something in stable, you send the patch to this mailinglist with
>> [STABLE] in the subject.
> 
> Which is exactly what I did.  Now 3 times even.

I suspect the problem is most of the people interested in stable do not 
know what this patch does. I admit to skimming over things that look 
like patches to pieces of OE that I know little about.

Still, we need a way to get this sort of thing into stable, even when it 
is outside the scope of most of the reviewers.

The good news is the queue of stuff to go into stable is not growing out 
of control, but we need to work out a solution to deal with "orphaned" 
patches.

Philip


> 
>> That way it will show up here:
>>
>> http://patchwork.openembedded.org/project/openembedded/list/?state=*&q=oe%2CSTABLE
>>
>> or for a complete historic view:
>>
>> http://patchwork.openembedded.org/project/openembedded/list/?q=oe,STABLE&archive=both&state=*
>>
>>> Let's not make it to complicated to maintain stable, so that it will die
>>> from us again :-(
>> Stuff needs to get into .dev first to receive wider testing. Putting stuff
>> directly in stable negates the idea of the stable branch.
> 
> Naturally, but (2 but's):
> 
> 1. When .dev is sufficiently different from stable, some fixes needed
> for stable will not make sense or work on .dev, so this rule will have
> to be bent once in a while, and most likely, more often when
> stable/2009 gets old.
> 
> 2. There must be a some sensible elastic, as straight out simple fixes
> IMHO, could just go in both at the same time.  But I guess, my opinion
> on this matter does not really matter.
> 
> It is quite impressive how difficult it can be made to submit what is
> mainly just a copy action of a file...
> 
> /Esben
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

  parent reply	other threads:[~2009-04-08 17:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07  7:16 [STABLE][PATCH v2] mingw-binutils: update to 2.19.1 Esben Haabendal
2009-04-07 12:29 ` Esben Haabendal
2009-04-07 16:51 ` Tom Rini
2009-04-08 14:16   ` Esben Haabendal
2009-04-08 14:26     ` Koen Kooi
2009-04-08 16:52       ` Esben Haabendal
2009-04-08 17:26         ` Koen Kooi
2009-04-08 17:38         ` Philip Balister [this message]
2009-04-08 17:50           ` Tom Rini
2009-04-08 18:02             ` Esben Haabendal
2009-04-08 18:14               ` Tom Rini
2009-04-08 18:09             ` Esben Haabendal

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=49DCE11F.90903@balister.org \
    --to=philip@balister.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.