public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gmail.com>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073))
Date: Fri, 12 Aug 2005 13:57:38 -0700	[thread overview]
Message-ID: <42FD0D42.3020500@gmail.com> (raw)
In-Reply-To: <42FC97C9.7050301@egr.msu.edu>

Alec Warner wrote:
> 
>   I have emerge rewritten ( somewhere ) for HEAD once all of Brian's
> config/domain/crazy stuff goes in, unless someone wants to unlease
> modular emerge now, in which case I can pull the code out of the cobwebs
> of my ${HOME} and work on it again.
> 
> Basically the code allowed you to have a folder for modules that emerge
> would detect at run-time, and load the proper ones depending on user
> specification.  The bonus to this was that some tools would be merged
> into emerge instead of being seperate, which many users got upset about.
> "emerge --rebuild" = revdep-rebuild -X for example.  The main problem
> with this is basically the same as above; emerge serves about 12
> different functions with crappy code everywhere, I managed to replicate
> about half the functionality by just copying and pasting important code
> everywhere, but most of it still needs to be completely rewritten (
> *stabs depgraph* ).  I was going to wait for the new API to be done ( no
> use rewriting emerge twice, IMHO ), but if you want it done now it
> wouldn't be a big deal.

Hmm, interesting.  I can see how building other tools into the emerge interface would be useful if it allows more code to be shared somehow (and less duplication).  Are there other reasons for combining other tools into the same interface?

My main concern about "rewritten" code is that, depending on the nature of the code being rewritten, it may be likely to introduce unwanted changes or regressions.  Of course, thats why I put so much emphasis on careful refactoring/reorganizing of existing code that is known to work in the desired way.

I don't see a reason to keep messy code around for long periods of time when it can be so quickly reorganized.  Why wait?  Messy code only makes more difficult the job of maintaining and improving the code.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list



  reply	other threads:[~2005-08-12 20:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11  5:08 [gentoo-portage-dev] PATCH: refactor emerge spinner (#102073) Zac Medico
2005-08-11 12:14 ` Alec Warner
2005-08-11 14:06 ` Jason Stubbs
2005-08-12  5:19   ` [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073)) Zac Medico
2005-08-12 12:36     ` Alec Warner
2005-08-12 20:57       ` Zac Medico [this message]
2005-08-12 21:48         ` warnera6
2005-08-12 22:10           ` Marius Mauch
2005-08-12 22:12             ` warnera6
2005-08-12 22:49           ` Zac Medico
2005-08-13  1:06             ` Jason Stubbs
2005-08-13 17:34     ` Zac Medico
2005-08-13 22:25       ` Zac Medico

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=42FD0D42.3020500@gmail.com \
    --to=zmedico@gmail.com \
    --cc=gentoo-portage-dev@lists.gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox