Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] distributed/peer-to-peer mirroring

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] distributed/peer-to-peer mirroring
  • Date: Mon, 4 Oct 2004 22:12:46 +0000

On Mon, Oct 04, 2004 at 02:47:44PM -0700, Seth Alan Woolley wrote:
> If somebody wrote a specification for how we would store that info, they
> can put it into a bug report and give the developers something to shoot
> at after it has been discussed and agreed upon by those involved.
> Otherwise, nothing will get done.

I agree, but going a little further, nothing will be done until we
actually reach a consensus on "what we want". Im not coding up, or
accepting patches for what seems to be a very abstract feature which I
still hardly understand.

Im not saying this isnt a good idea, or isnt one we'll do, nor do
I want to discourage the tossing around of new ideas. However be
aware that theres a lot of other older feature requests in sorcery
and we're just now starting to get the code cleaned up and detangled
from the previous anarchy of feature creep. I will probably always
come off as very conservative about what goes into sorcery.

I also will weigh my motivation on a feature with the amount of effort vs
amount of usefullness ratio. If 3 people actually want one big complicated
feature for a very specific thing, and 20 people think something else
(which requires less effort) would be useful, guess which one will
probably get worked on?

On that note, as far as major new features go (so long as I'm sorcery
king :)) they must have sufficient documentation (eg a spec) and be
clearly defined. I dont want to have a feature mutate into something else
and have to maintain it, and then have to hold meetings to figure out
what we really want, and then re-write it.

So first figure out what, exactly, it is that you want. Then we'll
delve more into implementation details. Expand the specification
to contain those details, then work on writing it.

-Andrew

>
> I prefer before we start writing code to sit down and think about the
> process and document it. This also gives documenters a better hope at
> understanding the implementation so as to better write it up for
> non-developers.
>
> I figure we take the depends info and put that in a file of a known
> location. Do the same with the configure file for persistent options
> and include a way of describing what architecture it is. To be unixy,
> we could put a lot of the critical arch data in the filename itself so
> finding the correct one is easy. Maybe we can include the last four
> digits of hash of the most important configure options in the filename.
>
> At least we should have three or four people bouncing around the "best"
> way in a bugzilla bug.
>
> Seth
>
> On Mon, Oct 04, 2004 at 10:50:02PM +0200, Andrew ruskie Levstik wrote:
> > I'm guessing we could expand this to also
> > include the cache(though that would need some data in the cache files
> > themelfs)
> > like optimizations and arch and config info.
> >
> > This would be usefull for those ppl that acctualyl want binary only.
>
> --
> Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
> Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
> http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
> Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


--
___________________________________________________o.org__________________
Andrew D. Stitt | astitt at ssourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | |
|Sorcery Team Lead, Porting Team Lead | |
|Grimoire Guru ham/smgl | ftp://t.armory.com |
|Author and Maintainer of Prometheus | |
--------------------------------------------------------------------------

Attachment: pgphDLmq143_1.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page