From: Paul Sokolovsky <pmiscml@gmail.com>
To: "Sergey Lapin" <slapinid@gmail.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Palms commits.
Date: Tue, 10 Jul 2007 21:16:08 +0300 [thread overview]
Message-ID: <40479847.20070710211608@gmail.com> (raw)
In-Reply-To: <48239d390707100845o17a49392vcbf74fd5991b77f3@mail.gmail.com>
Hello Sergey,
Tuesday, July 10, 2007, 6:45:11 PM, you wrote:
> Hi, all!
> I just had raging argument with Paul Sokolovsky about my commits,
> so I'd like to RFC them, and also I'd like to ask if all these changes
> should be passed through RFC.
> Please, see attachments. Sorry for post-factum.
> Briefly, these commits generalize palms support and make maintenance
> easier, also, update Zire 72 configuration.
Well, I regret that even after discussion on IRC you still miss the
point. The talk was not about "palm commits" per se, but about
refactors to make machines more maintainable. OE obviously has
noticeable problems with that, and trying to solve them in local
machine corners won't benefit OE, but in the end just will become the
same mess but in the other plane.
So, if you have bright ideas how to optimize maintenance, please
think how it fits with already existing machine support framework
(task-base), share them with wider audience, and call for feedback.
I'm sure there're parties interested in the same changes, and getting
together may lead to much better result for OE as a whole.
Of course, you're free to treat those changes as Palm local, but
what I wrote still holds - machine configs in OE need refactoring and
elaboration. If you don't want to put a bit more effort into that and
make your changes useful universally, then someone else will need to
duplicate large part of your work, and possibly achieve incompatible
results with your current scheme. As that someone hopefully will
target it on global level, then palm config would need to be changed
too, so in the end it will appear turn out that you lost time too.
Summing up, by investing 50% more effort into that, there can be 5
times more outcome. And as a "fresh blood" in OE, you're in good
position to lead this, as other developers are of course stuck with
other issues.
> Thanks a lot,
> S.
--
Best regards,
Paul mailto:pmiscml@gmail.com
next prev parent reply other threads:[~2007-07-10 18:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-10 15:45 [RFC] Palms commits Sergey Lapin
2007-07-10 18:16 ` Paul Sokolovsky [this message]
2007-07-10 19:11 ` Sergey Lapin
2007-07-10 19:58 ` Michael Krelin
2007-07-10 21:08 ` Paul Sokolovsky
2007-07-10 21:01 ` Richard Purdie
2007-07-11 12:59 ` Sergey Lapin
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=40479847.20070710211608@gmail.com \
--to=pmiscml@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=slapinid@gmail.com \
/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.