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: Eric Sandall <eric AT sandall.us>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] OFF-TOPIC bi-arch request WAS: ISO generation
  • Date: Wed, 26 Jan 2005 17:47:25 -0800 (PST)

On Thu, 27 Jan 2005, Laurent Wandrebeck wrote:
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.
Stop it right now. You seem to forget that sorcery is necessary to install
a system with an iso. Several people asked for an iso that supports
something else that pure x86. If sorcery aim is to be pure x86,
that simply _sucks_.

It's not that we're planning on never doing multi-arch, it's that we
have higher priorities: a.k.a. x86, and then PPC (in that order, IMO),
though PPC requires little extra work than x86, unlike x86_64 or
SPARC.

Please try not to stray WAY off-topic in this discussion. This is a
discussion about iso generation.
I am not off topic. sorcery is one really important point.

We're currently talking about how the ISO should be generated and how
the ISO Team is to work together, not on adding new architectures that
require more work for other teams that already have tasks to complete.
Multi-arch is on the queue, but it's for post-1.0.

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.
I have understood, but your decision is not the right one.
About 10 people interested in other archs, and you dare to say "nah,
we'll just support x86". Do you have any idea of the number of people
that uses SMGL ? 10 people is quite a bunch !

What he's saying (IMO, Andrew, feel free to correct me ;)) is that the
"10" (if it is even 10) people who "want/need" multi-arch are a
minority and that we have higher priorities (such as bugs and features
that we agreed on when 1.0 was planned). You don't see me saying that
multi-arch won't be there for my SPARC. ;)

To put it in perspective, check out http://stats.sourcemage.org/. Our
codex.sourcemage.org has an average of 554 visits per day for this
month alone and www.sourcemage.org gets 351. Now don't take me wrong,
I'm not saying that 10 people don't matter, but what I am saying is
that these "10" people (or however many need x86_64 or SPARC) are a
minority and we have quite a few other people to work for.

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
bi-arch is mainly a sorcery question. OK, there are others things to do,
but bi-arch is certainly not one of the features to consider as
unimportant.

It's not unimportant, but rather marked for later implementation.

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
we don't have a consensus on the way to follow. Why ? because the
leader didn't show any real path to follow. Now, as we need to progress,
we can't allow us to simply wait.

Which is what this thread is intended for, rather than talking about
Sorcery features or Grimoire bugs, unless those pertain to the items
listed for the 1.0 ISO.

(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,
already too small team. that's perfectly right. Several sections are
unmaintained, bug number is still too high to have something we can
reasonnably call 1.0. And you want to kill a feature that would leave
something like 10 people offroad ? 10 people is important, do not
overestimate the people in and around SMGL.

This distro /is/ about the people; developers and users. We're not
trying to throw people out or deny them usage of SMGL, but rather to
improve our current system that applies to most of our users. Keep in
mind that the "pure" 64-bit systems can work just fine, and if you
need 32-bit you can do as Seth suggested and have a chroot or UML
system to run those programs until we have time to implement
multi-arch. You're asking our developers to set aside time for a
minority rather than focusing on the majority so that the minority
doesn't have to do extra work to have what they want.

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?
basics are there. we have a bi-arch iso in testing phase. i've even an
installed system thanks to it. Moreover, it is _not_ my "fringe feature",
i'm not the only one wanting to run a x86_64 system in native mode.

The current code that we can all see (//sgl/sorcery/proj/proj2) is
/not/ workable and does not build a multi- or even bi-arch system.
The only reason we have that branc is because someone (me) took a
little time out of his schedule to pull in someone else's work
(Benoit) into Sorcery to try and add a feature that he (me again)
didn't quite understand. I didn't have time/inclination to implement
everything (while Benoit had patches available for most of his work,
the main part, bi-arch, was all in one script and not separated and so
would have required more time than I had at the time).

We already support native x86_64 in Sorcery. :)

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.
Did you see any other iso better than that ? i've installed it
over a couple of boxes without any problem. And please, please,
stop saying people that what they do is crap. We're already too few.
Do you really want to maintain SMGL alone ?

Just because there's nothing better doesn't mean we can't improve upon
it. While you (and others) may not have had problems, some did. I
don't believe we're saying (or trying to say) that what anyone did is
crap. In fact, without all our prior contributors we wouldn't be where
we are today (which I think is pretty good :)). I believe what he's
saying is that 0.9.3 had a few bugs that annoyed several users (we had
more than the normal amount of questions about the 0.9.3 ISO not
working).

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/.
It is not a partially implemented form, as we can have a complete system
with it.
the point is, we need to maintain a patched sorcery, and some patched
spells.
Meaning, more work to get that ongoing, because main branch doesn't want
to accept an already tested feature that works. And, again, please stop
considering 10 people is nothing. In rh, mdh, debian world ok, not here.

If you have to patch spells, file bugs. You did file bugs, right? How
else are the spells to be fixed if we don't know about them? As for
patched Sorcery, use the //sgl/sorcery/proj/proj2 branch to modify
Sorcery to work on your arch/multi-arch if you truly need it. You can
send patches to me if you don't want to use Perforce. The proj2 is
already branched from devel and so, once multi-arch is working fine,
can be (fairly) easily merged back into devel and voila, we have
multi-arch in devel with little fuss and not breaking/intruding on
other's work.

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.
A consensus ? well, do you really want 1.0 to come out this year ?
We're late, for sure, in year 2002 we were already discussing on 1.0 !
(for 2002, of course)
Waiting for a consensus, well if members don't try to progress, I'm afraid
we won't have another iso until, well, quite a long time.

We're late because we don't care about competing with other distro's,
gaining market share, setting a schedule, etc. as much as we care
about making this a distro we're proud to use and has the features we
(the users and developers) want in it. If you don't think we're making
progress you definitely aren't watching all the commits our developers
have been putting in (on weekends there are usually over 100 commits
from all the teams).

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.
ISO team is a mess. why ? no real leadership. one wants an iso spell.
another one wants new features. one reworking existing scripts. another
one
working on splitting scripts. and another one working on improving this
and that.
Features being refused, new things that simply don't work etc.
ISO team is forking on its own ! Too few people, working on different
things,
instead of working on things that have proven to work, even if they're not
perfect. Did you say that 10 people were meaningless ?

Which is what this thread is for: to determine what direction the ISO
Team is going to take:
1) Focus on creating easily scriptable and modifiable ISO generation
scripts or
2) Focus on getting an ISO out the door with all the bugs filed
against the last ISO fixed or
3) A combination of the above

The nice thing about the "forks" of the ISO code (if they were done
properly) is that, when we're all done and decide one, we can
integrate it back with Perforce into the main branch.

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.
Rehashing the same question is important, esapecially when decisions
taken are not the right ones. Taking volunteering people off, is not only
losing users.

Who did we remove from a Team that didn't want to be removed?

As it is late here, i will reply in the same mail for several people:
to Karsten: "Time is not to worry about new features". But that's the
reason
new versions of sorcery and smgl 1.0 are postponed. And you want to
neglect already tested features that will satisfy a bunch of devs and
users ?

They're postponed because we decide that, in order to finish what we
want in 1.0, we need to add more features/bug-fixes/libraries, not
because "we want feature X because it's cool". What already tested
features are we not including? If they're already tested then they're
in Sorcery (either devel or test, maybe even stable) or in the
grimoires (probably test, maybe stable). If a bunch of developers and
users want the feature that's already tested then it's already been
well tested and added to the respective components.

Concerning ISO, and getting from a one-man dev to a decentralized model,
when benoit was creating isos (or myself), in 0.7, 0.8, 0.9 days, there
was a small team, but we were working hand in hand. So decentralized
was functionnal. Now it doesn't because some think that existing things
aren't good enough, even if these things have created more than 10 isos.
Everyone's working in his corner, winning for approval, waiting for lead.
Where will we land, or at least most of us ? in a trash. that's
ridiculous.
What a waste of time :( About buggy installer, i must have tried,
installed
something like a hundred isos. Buggy installer, as you said, is not so
buggy. OK, it hits a couple users, (a FB joke prolly) but that really far
from
a majority. Every program has bugs, and installer don't have really
serious
ones.

The point of Karsten's work (IMO) is to make the scripts easily
modifiable to work for any architecture, on anyone's machine, and
without much knowledge of how the ISO works. We're also wanting more
of a review process (much as Sorcery and the Grimoire have now) of
what fixes/patches go into the ISO as well as opening it up for more
developers to help.

To Seth: Bi-Arch isn't important ? we have something like 30 people
in and around smgl (devs, bug reporters, testers). And you want to get
rid of 10 !? Pure 64 bits ? quite a bunch of programs simply won't run
or compile in a pure 64 bits environment. Can you tell your users, your
boss, or yourself, I won't use that proggy anymore ? I can't.
"hmmm sorry guy, you'll have to forget that one, doesn't work with your
new system. evolution is great don't you think ?" About having a good new
basic ISO ongoing, are the previous ones not good enough ? Did
anyone give kiss-the-ass new isos ? No.

We're not saying the prior ISOs are crap. We're saying we want them
"cleaner" (in our minds, more modular and easily configured) as well
as well understood by more people in the development of SMGL. We're
also not trying to get rid of 10 people (not all of whom are
developers) and you can work around the pure 64-bit problems; one way
is how Seth mentioned: using a chroot, there are other ways.

Perforce, a nice tool. Well could be. Doesn't support symlinks, history
seems to be lost when files are moved (i'm far from a p4 expert so i hope
i don't say
any mistake). We can't merge that feat, oops, sorry, that's simply people
that don't
want an interesting tested feature. Having three iso codebase is simply
crazyness
in smgl situation. losing time, making 1.0 an illusionnary goal, being
postponed,
and postponed, and... You say you weren't able to contribute to ISO, but
as far as
i can remember, i was the one who commited scripts into p4. I've _never_
rejected
someone who tried to help. Even if i'm a crappy leader (and I know it).
Your install
guide was integrated for example.

We don't lose histories when files are moved and we don't really need
symlinks (that I know of). The three codebases (if done properly,
which I believe they were) can be easily merged back into the main
branch (or any other branch). This thread is meant to talk about those
branches and which one, or combination of them, we are supposed to use
for the ISO. I've already talked about your "interesting tested
feature" (I'm assuming you're talking about multi-arch) and that,
according to our records, it's not implemented as a working feature
and not tested or much talked about.

You're also talking about leaving
skunkwork dev
style, letting people help. Why the hell is devel grimoire still not
available to people
other than devs ? Aren't free/gpl/ open source software supposed to let
anyone see
and contribute to stuff ?

Devel branch is available for those who want to work on it; we're not
hiding it. However, we found that if we make it easily available (keep
in mind the GPL doesn't require one to make their code "easily"
available, only available at a reasonable "cost" [not necessarily
money]) then our users will try to use it and then complain when
something doesn't work or we destroy their machine. So, you have to
ask to get it and then you can't blame us if it dies. :)

There is _no_ french sector. BearPerson, erics,
sandalle,
alley_cat, hamish, and loads of others were/are part of the team. isos
were created
by several people, adam, hamish, benoit, karsten, myself...you're talking
as if there
were some kind of lock on iso. that's wrong. You're talking about a single
arch iso,
but, ppc isos are already existing, x86_64 is coming, and you want to
simply forget them,
so x86 can be more stable, and then give more work to get (again) pcc and
x86_64 ?

No, that's not quite what we're (at least I) are saying. What is being
said is that x86_64 (a.k.a. multi-arch support) requires more work and
time than we can alot to it and that we should stabalize and clean up
our current ISOs (currently x86 and PPC).

Also, I would appreciate it if people didn't start personal attacks/flames
(i.e. "french sector") while we're trying to discuss what's going on;
it only detracts from the discussion.

To David: No, we are not close to 1.0, it has been postponed for at least
a month.
But I'll bet on at least 4 given the current situation. Quite big features
are to be
implemented in sorcery (correct resurrect etc) so why not bi-arch ? Don't
you want
To attract new users ?

The new resurrect is almost done (according to Andrew), whereas there
is no working code (that we've seen) for multi-arch support. We do
want new users, and while an x86_64 ISO would bring in some, having
nicer (not that the prior ISOs didn't work or weren't nice, but
nothing is perfect in any project) ISOs will also attract more and
from a larger crowd.

So, at last, to conclude (1:00am here, need to go to bed).
Sorry for being rough, and maybe rude. I just want smgl to keep improving,
so,
things are better when they are said. I don't want to spit on anyone. If
ones can't bear
my opinions, then so be it.

Opinions and criticism are always welcome, as long as it leads toward
a goal. And we're aware (I hope) that not everyone can speak English
natively.

I don't want to give orders to anyone. But
take smgl history,
the "other" fork (lunar, not to name it), has got 1.0 out months ago.

Comparing us to other distros is not a good way to engender more work
being done. We're not targetting to beat "the other guys", but rather
to be what we, the users and developers, want our distro to be (which
includes quite a few things, not all of which we have done yet).

We
are still
fearing to recompile glibc, aliens... Let's be brave. We have not been
good (myself
included) as managers to get smgl right. D'ont you think it is time to
lose pride,
recognize our errors, forget our pitifull quarrels between french, and
whatever,
take _decisions_ (without letting letting the third off the team
off-side;) so we can
really progress and try to respect at last a realistic roadmap ? (please
forget
i think that, we should, it would be better to etc).

What is unrealistic about our ISO roadmap? Please bring up specifics
if you see problems so that we can discuss them. File bugs for
problems you see so that the proper teams can fix them and keep in
mind that not everyone has the same priorities as you (not you you,
but the collective "you" of everyone ;)).

Bah, I was pretty upset tonight. I hope that will lead to something better
(forget flames, i will ignore, but if your comments are too insulting).
PS: sorry for the typos (there must have some).
PS2: i hope i've been clear enough, english isn't my mother language.
Regards,

Let's bring this discussion back on track: Discussion of the ISO
scripts and what we're to do with/about them.

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/




Archive powered by MHonArc 2.6.24.

Top of Page