From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Worried about patches not being merged?
Date: Fri, 20 Mar 2015 17:02:29 +0100 [thread overview]
Message-ID: <20150320170229.16a1de9b@free-electrons.com> (raw)
In-Reply-To: <CA+TH9V=wUa6Sh+uszjndiy-FaHsxzbVuvjAFcQWVxTg=qEeJTw@mail.gmail.com>
Angelo,
On Thu, 19 Mar 2015 23:27:22 +0100, Angelo Compagnucci wrote:
> I have more or less done, I think in the WE I can push a patch to have
> tags attached to patches.
Awesome. Another thing that would be great in the long term is to make
the patchwork UI a bit reactive (Ajax stuff, etc.).
> > Ah, really? Could you describe a bit the workflow / how it would work ?
>
> I have to find more time to elaborate if that software could be bended
> to buildroot needs. I have only a superficially view right now. I
> promise to look better at it.
Ok, thanks.
> > Well, is there really such a huge pile of new packages / medium level
> > patches / newbie patches ? We tend to apply them fairly quickly, in
> > general.
>
> Yes, but I have the impression that patches tends to accumulate in a
> stack fashion, so the patches served are the last arrived. If a patch
> slips out of scope, it takes some time to get reviewed/committed. This
> is wouldn't be a critic to your great work nor the work of the other
> great reviewer/committers!
Yes, I agree this is what happens, but there is more or less a reason
for it. When a new patch arrives, if it's a fairly trivial package
bump, hash addition, or new package addition not raising any particular
question, then it's just good to apply it quickly so that it gets out
of the way.
Then, what happens is that what remains from this quick effort are the
more complicated patches, that tend to pile up.
Whenever I spend an evening applying patches, I generally try to work
in two passes: first a quick pass on all the trivial stuff of the day
(or past few days), and then a second pass during which I try to handle
a few older patches.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
prev parent reply other threads:[~2015-03-20 16:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 22:21 [Buildroot] Worried about patches not being merged? Thomas Petazzoni
2015-03-18 20:01 ` Jörg Krause
2015-03-19 8:20 ` Thomas Petazzoni
2015-03-20 15:33 ` Jörg Krause
2015-03-20 15:37 ` Thomas Petazzoni
2015-03-19 8:35 ` Angelo Compagnucci
2015-03-19 9:16 ` Thomas Petazzoni
2015-03-19 9:34 ` Angelo Compagnucci
2015-03-19 10:25 ` Angelo Compagnucci
2015-03-19 10:26 ` Thomas Petazzoni
2015-03-19 10:45 ` Angelo Compagnucci
2015-03-19 11:09 ` Thomas Petazzoni
2015-03-19 22:27 ` Angelo Compagnucci
2015-03-20 16:02 ` Thomas Petazzoni [this message]
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=20150320170229.16a1de9b@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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