Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] OFF-TOPIC bi-arch request WAS: ISO generation

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] OFF-TOPIC bi-arch request WAS: ISO generation
  • Date: Wed, 26 Jan 2005 11:51:17 -0800

On Wed, Jan 26, 2005 at 07:55:01PM +0100, Laurent Wandrebeck wrote:
>
> Le 26/1/2005, "Andrew" <afrayedknot AT thefrayedknot.armory.com> a ?crit:
>
> <big snip>
> >I would have to say its a better approach for the long term to have
> >our software be modular so that architectural differences can be
> >encapsulated in those modules and configuration data. Then the higher
> >level tasks can be driven by configuration details to use whatever pieces
> >of modular code are necessary. In the end, the modular approach becomes
> >less complex than the more monolithic approach of having everything in
> >one script for "ease of maintainence".
> <snip again>
> AFAIK, right now, sorcery is some kind of modular (archspecs etc).
> But, some arch (sparc, amd64, em64t, and maybe others i don't know of)
> need a particular path for {bi|multi}-arch support. Do you think it is
> possible to make it modular ?
> My very little knowledge of sorcery would say no, but you are for sure
> the one that can give the right answer.
> If it isn't possible, then what to do to support new arch ? I see three
> solutions:
> 1st would be to integrate {bi|multi}-arch support into sorcery. So, it
> satisfies everyone.
> 2nd would be to maintain several branches, increasing work load in an
> already too small team.
> 3rd would be to refuse {bi|multi}-arch integration, making about 10 people
> prolly unhappy.
> Of course, having pure 64bits ports would be some kind of a solution, but
> some software programs won't run in 64 bits mode, and no one can say when
> they will. Quite annoying.
> If making {bi|multi}-arch support modular is easy, then forget what is
> written above ;)

Just curious why do you keep bringing up bi-arch support at the drop of
a hat? I didnt even mention sorcery in that email...Its like everything
is seen with this lens that distorts whatever is being discussed to a
bi-arch discussion.

Please try not to stray WAY off-topic in this discussion. This is a
discussion about iso generation.

I will stick with what I said in the meeting, which you didnt quite seem
to understand, but I'll repeat for repitition sake :) Maybe it will get
through this time? Lets see if it does.

bi-arch is a feature of both the iso and sorcery, if you take a look
at sorcery bugs theres quite a few other things to do already, if you
look at the iso team, we dont even have a consensus on how we're going
to make isos or a reasonable installer, why would we try to spread our
(as you say) "already too small team" over another feature that only 10
people need? If and when the iso team is going to commit to having
bi-arch iso's and we have a consensus on iso generation (!) sorcery
will be there with bi-arch support. As it stands currently like i said,
we dont even have the basics down yet, we have a very small iso team,
we have a very small sorcery team, why would we implement your fringe
feature over having an iso that the majority of the x86 world could use?

I'll address your three "solutions"

1) it wouldnt satisfy everyone, it would satisfy 10 people as you say
in case 3 in fact, having a consensus on iso generation would mean better
isos, which would satisfy quite a few more people than just 10. It would
bring new users, given the experiences of users who try out 0.9.3 iso,
im surprised we have /any/ new users.

2) its already in a sub-branch in its partially implemented form, which
is actually less work for for "the already too small team" because we dont
have to fix bugs related to it, or support it when only 10 people supposedly
need it. However that doent mattter anyway because the feature isnt
even fully documented or designed because for the reasons I ellaborated
upon above, we're not ready with the basics of iso generation, so we're
not going to go for some obscure feature that only 10 people want, when
instead we could implement features that will benefit everyone /right now/.

3) im not refusing to do this feature, im refusing to do it until we
have a consensus on iso generation, a stream of reasonable uni-arch isos
(oh yea those!) and its a commited iso team project in the near future.

Ive said before and again, that when the iso team is actually functional
and capable of addressing more advanced projects sorcery will be there
to greet it, but right now theres a lot of other work to be done first.

I dont really have time to repeat this anymore, so please think carefully
about bringing up bi-arch support and re-hashing the same questions. Im
not saying we cant ever talk about this feature, its just I am going to
have the same answer for you until the things ive said change.

-Andrew

--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
|Sorcery Team Lead | ftp://t.armory.com/ |
--------------------------------------------------------------------------

Attachment: pgpWfxNqIHdNt.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page