Public SourceMage Discussion List

[Mark Andrews <msasgl AT msa-enterprises.com>]

Hello Ryan,

Saturday, October 5, 2002, 5:02:18 PM, you wrote:

RA> GCC flags, as currently supplied via sorcery's config menus? It
RA> automates that, correct? So what is really being started here is an 
RA> abstraction of the compiler optimization flags out of sorcery and into 
RA> the compiler's spell, to allow for IBM compilers or Intel compilers, or 
RA> whatever, based on what is installed.

Sounds like a fair summary.

RA> This is virtually guaranteed to NOT work in sorcery 2.0 at all, since 
RA> one of the primary goals of sorcery 2.0 is to make all sorcery code 
RA> independant of the spells and vice versa. In other words, to make it a 
RA> package management system, with independant packages.

Does this mean sorcery 2.0 won't have cast? That's the only thing that
would really make this irrelevant.

>> RA> 2) It will not work in sorcery 2.0 at all.
>>
>> It's a bit premature to say that don't you think?

RA> Possibly. But I would be willing to go as far as to say nearly 
RA> everything we have will not work "out of the box" in sorcery 2.0 - 
RA> There are a LOT of roadblocks encountered in the 1.0 codebase that we 
RA> have had to work around. I fully expect that in 2.0 we will be 
RA> rewriting to remove those roadblocks.. which will change basic formats 
RA> around a bit. Obviously this wont happen overnight, but instead will 
RA> happen over time. The 1.0 base will have some legs.

Again, sounds reasonable. The libvariables stuff I suggested doesn't
use the 1.0 base but would work alongside it allowing a gradual
migration. In an earlier message I did actually state that cpudetect
was an add-on to sorcery. The libvariables stuff just seemed to
streamline some stuff in the sorcery base so I expanded the idea and
described it so the sorcery team could see if there was value in
adding it to the base. 

RA> Mark, I did not summarily dismiss your work in any way shape or form.

"2) It will not work in sorcery 2.0 at all."

Sounds pretty dismissed to me.

RA> In fact, I quite like it. What I did do was reply to your email stating 
RA> (for the first time) that you will integrate autocpu into spells

Where did I say this?

Was it when I said "it should probably be a part of the gcc spell" ?

RA>  and 
RA> such with a comment that touches on many discussions we have had over 
RA> the past months regarding sorcery and where to take it.

Again, I figured this hence why I brought it up now for open
discussion.

RA> And all I said was that the closer you tie it to the current
RA> system, the more it will need a complete rewrite. This is a FACT.

If you re-read my message you'll see that I'm actually moving it
further way from the current system. The "autocpu" code will actually
just be a translation layer from cpudetect to sorcery. This
translation layer is all that needs changing to make the code work
with any distro. Not a complete rewrite at all.

RA> Even if you DO, I wont have someone running through
RA> the codebase changing code that is being maintained by another. For 
RA> example, you would be stepping on the toes of the gcc maintainer, the 
RA> sorcery team, and just about everyone who has done any thought about 
RA> where to take things post 1.0.

You missed the point entirely. I'm not proposing changing anyones
code - that's their job. What I was saying is here is how I am doing
this, here is how it could be used to make life easier.

Quoting myself - "Anyway, if the gcc maintainer or anyone else wants to
have words with me, you know where I am." - perhaps that wasn't clear,
but what I meant was if the gcc maintainer wants to get in touch to
make sure what I am doing is compatible with what they are doing /
planning on doing, then do so.

Quoting myself again: "So here is the first draft of the new variables
which will be available, send comments & suggestions to the usual
address:" Maybe this wasn't clear either, but what I meant was this is
a draft spec if you think it should be different let me know.

Where you got the idea that I'm going to be changing any of the existing
codebase from I have no clue.

RA> maybe you shouldn't just post "this is how its going
RA> to be" and get upset if someone points out an incompatibility in your 
RA> idea.

I still don't see this "incompatibility" and I feel perfectly
justified in saying this is how I PLAN on doing my code and asking for
feedback.

RA> SourceMage development is driven by developer consensus, based on user
RA> needs AND development ideas/goals. I dictate nearly nothing (and have 
RA> actually been asked to give MORE "this is how it is" type of direction 
RA> by some). That said, I comment on almost everything.. challenging 
RA> people, trying to share information, and working to get people to look 
RA> at the big picture and what others are doing before they just 
RA> "announce" (as you did) that something will be the way they want it... 
RA> because that leads to their work not being used, or being used only 
RA> partially.

The only thing I announced will be they way I want it, is the next
version of cpudetect, and given the numerous times in that message I
asked people to "have words" or "get in touch" it's obvious that I am
considering what others are doing and inviting their input into the
process. Again where did you get this idea that I'm trying to say "this
is how it is"?

RA> What it DID do is point out that your current plan has flaws
RA> when tied into the rest of sorcery, as well as when tied into the 
RA> current thinking on the 2.0 direction.

What flaws? Specifics I can fix, vague "your code isn't compatible
with an idea they may or may not become part of sorcery 2" I can't do
a thing with other than waste time writing silly emails!

RA> You can take that two ways:
RA> 1) As a hint that you should probably get more involved in what the 
RA> rest of the team is doing before making summary choices about 
RA> architecture.

What summary choice? Where is this strange decision I supposedly made?
I thought the various emails and wiki stuff I did was becoming more
involved.

RA> or
RA> 2) As a summary rejection of your work completely requiring you to
RA> threaten to leave the distro or imply nasty things about the distros 
RA> leadership.

Given that my email was describing the way I plan on doing things
and inviting feedback, I could only see option 2) for your sending the
reply you did.

RA> It was meant as #1, and after having reread it a few times... it IS #1, 
RA> though without any padding and handholding.  How you choose to take it 
RA> is up to you. I hope you can see it as what it was.

A rushed reply that didn't consider all my points?

RA> But you can't develop changes to the gcc spell and sorcery
RA> libraries without understanding what the various current
RA> developers are doing and planning. It doesn't work that way in 
RA> a team environment.

I think I've covered this once or twice already. But just in case:

1) My message was a heads up for the gcc maintainer and interested
parties that what I was doing might affect what they are doing.

2) The libvariables is part of cpudetect not sorcery. However it
may be suitable for use in a future version of sorcery. Again a heads
up for the team to see if it is of use to them.

3) If I have to be aware of everything everyone is doing then I might
as well go solo and build my own distro. The point of getting involved
with existing teams is to spread the load. Why you saw my message as
anything other than "here's what I'm doing, it might be of use in
these areas" I don't know.

-- 
Best regards,
 Mark                            mailto:msasgl AT msa-enterprises.com

Sanity Warning: Dry British humour may be contained in my messages