All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Lapin <slapinid@gmail.com>
To: Paul Sokolovsky <pmiscml@gmail.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Palms commits.
Date: Tue, 10 Jul 2007 23:11:48 +0400	[thread overview]
Message-ID: <4693D9F4.5030000@gmail.com> (raw)
In-Reply-To: <40479847.20070710211608@gmail.com>

Paul Sokolovsky wrote:
> 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.

And I was telling you that in my position, such big start is doubtful,
if not impossible by several reasons, among which I need to learn
infrastructure mechanics in OE, and I need to get more time and effort,
because of busy schedule. So it is not possible _immediately_.

Your argument still amazes me.


> 
>   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.

I never disagreed on this thing, since it is generic enough as a concept.

> 
>   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.

I understand your point here, but if I prefer only start doing
something when I can handle that thing, and when I can be
responsible for it. If at the moment I can finish 1 little thing,
then that's what I'm going to do. If I have resources to spend on
bigger problem, I go and solve one (or help somebody with even bigger issues).

I have a list of smaller thingies I can do just passing by, and bigger ones,
which I leave for bigger windows of time.

Do you understand my time management better now? That's probably would
clear our discussion?

> 
>   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.

Do you count yourself in this 50%, btw?

Best regards,

S.




  reply	other threads:[~2007-07-10 19:17 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
2007-07-10 19:11   ` Sergey Lapin [this message]
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=4693D9F4.5030000@gmail.com \
    --to=slapinid@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=pmiscml@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.