Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO generation

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Laurent Wandrebeck <low AT low.ath.cx>
  • Cc: sm-discuss AT lists.ibiblio.org, afrayedknot AT thefrayedknot.armory.com
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Wed, 26 Jan 2005 13:05:31 -0800

At this point, I just want a pure 64-bit amd64 iso. I have no care for
a mixed mode environment and if I wanted one it would be simple to make
in a chroot on 32-bit with a tar or two (as a mixed mode on the same
filesystem requires two complete sets of libraries as well as binaries,
it's not that much different). If a program doesn't work in 64-bit
mode, I probably won't be using it anyways. If somebody is running an
obscure program that needs 32-bits, why are they running a 64 bit OS for
it?

Anyways, Andrew's priorities to get a good basic ISO going is
well-placed. Remember that the ISO has been a source of frustration due
to commitments and then delays (with h*g especially), and a few people
outside of the main team have done quite a lot of work and even feel ok
using perforce so we can see where progress is being made. I'm not sure
why your development has to go outside of perforce. If I'm working on
anything -- (as long as I have permission) it goes into perforce pretty
much within minutes of a natural stopping point. And now that we are
using proj* setups and have the expertise to use them, there's really no
reason to not use perforce's advanced features.

Right now we have three iso codebases and we have a tool that can merge
them together in cooperation: perforce. We should use it rather than
not have an answer when people ask if they can help on the ISO. The
standard model of introducing somebody to a team of getting them access
to watch commits and then letting them dive in when they learn the
basics so we can correct as they commit is something that could work
here, but I'm not sure why it isn't done. I know I wasn't able to
contribute to the ISO until hamish put it in perforce and I was able to
write an install guide (gradually being obsoleted) and fix some bugs
(like jfs support). I just like to see it being updated as improvements
are made, otherwise, am I to assume no work is done on it? Each time in
the past there has been work done on it in your "skunkworks" style of
development, but I think as we approach stability with 1.0 we need to
abandon the skunkworks mode of development and work with our SCM to
allow our developers to work together better. Even if we need to fork
off a proj* base and then merge later, we can still use perforce for
that to see how the development is going and each proj* can integrate
back and forth changes to keep synchronized as they each feel fit.

So really, two things here: I like a solid single arch iso for now and
to see the "french sector" use perforce as it was intended (as in more
frequently), so we can avoid "ha**sh"-style backlashes, not that this
will repeat, but I would just like to avoid it.

Seth

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 ;)
> Regards,
> Laurent.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

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

Attachment: pgpaEUGonJnlE.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page