Public SourceMage Discussion List

[Vlad Glagolev <stealth AT sourcemage.org>]

Well, hello there

The thing I must start with is that my aims in development of SMGL have
not changed since 2011 or 2010 and maybe even 2009. So actually I'd
like to continue following this course.

Since we have new powerful stable sorcery (thanks to Jaka), with new
shiny and modern features, I'm not afraid for this SMGL subsystem
anymore. I hope improvement of sorcery will be continued also with
help of all of us.

I'll push testing, ISO, documentation, web-presence and mirroring
problems to our PL :) (though I'll try to help him with a few of them
below)

But Grimoire needs more love too and we know that. As I said before, my
ideas aren't far away from those I mentioned in July, but I'll try to
keep them in context of Grimoire-only.

1. Stability for base image.

I'm for this with my all hands. But stability tends to be a relative
thing. And it depends on a lot of stuff, like testing and automated
process. David has some ideas about automating the future testing
process which would prevent new releases being rolled out with epic bugs
(like something doesn't build and such). This thing can be scripted,
yes. But primary idea here is to support every option and we should
look forward for the modern systems too.

This means we must reselect spells for basesystem/chroot image testing
according to the modern world. Like kbd deprecated console-* long time
ago, but we still don't care. here's the list I'm talking about:

* missing tools for new filesystems
* dropping of deprecated stuff
* missing new implementation for ping (maybe we need to switch to
inettools or how it's called now) and such basic tools
* update smgl-archspecs for new modern CPUs according to new GCC
* you can continue the list...

Look, we won't have too many spells here, so let's script compilation
of them with every option they have for automated testing process.
Yes, this won't fix every error (like in some specific configuration),
but, as David told, we must start with something simple, and imho that's
a good point for that.

After doing so we could have automated chroot-image generation for
both archs we support good enough (i686 and x86_64).

Also something tells me that 1 month isn't enough for new release to
include all tested stuff, even tested by upstream itself. I think we
might shift it to 2 or 3 months. But that's just a thought, born by
day-by-day grimoire work during the last years.

2. Stability for Grimoire.

That's a question for branches and test vs. stable releases.

First of all, read this carefully:
http://wiki.sourcemage.org/FrequentlyAskedQuestions/DiffGentoo

especially "Sensible vs. Upstream Defaults" and "Multiple Versions,
Masks, and QA" articles.

and never forget about SMGL roots when you commit stuff. Select branch
as stable only if it's marked stable by upstream and doesn't conflict
with our global distro settings which depend on other upstream defaults
(like udev issue we've seen recently).

Speaking of bumping... don't simply bump the spells, please, but read
the changelogs for security info, new configure options, new and
dropped dependencies. if you create a new spell -- try to include as
many configure options in DEPENDS and CONFIGURE as possible. This will
take more time, yes. But it's better than bumps for bumps, which won't
bring the project to a better world, really.

According to this, I'd like to take QA position (at least for Grimoire)
also, to check, fix and recommend stuff when and why it's proper to do
(like different spell files for different operations) and do not for
new developers or for those who just doesn't care :^)

If we speak about branches (devel-libpng, devel-xorg-modular), I'd like
to see them integrated but with a lot of testing before this.
Everything can be scripted, that's proven world-wide, so why can't we
do that? :) The only things come to my mind are laziness and lack of
hardware. I remember David promised to give us a few of vms for such
stuff... but until that, I think, we need to confirm #1. If we have
stable and modern chroot image -- it's easy to extract, merge and check
upgrade with integrated new branch into it, while not killing the live
system if something goes wrong. That's the point. Of course for brave
enough it's allowed to test them on their live systems, but please,
don't commit changes unless you're sure upgrade goes smoothly and all
issues are fixed for that automatically (not by handy fix of cleanse
and such, only on your own system). That's a real problem, and the
primary reason I avoid presence of any branches in test (which one day
becomes stable).
One of the good examples is located in bug #319 which is still
unresolved: we can't roll out a stable release with such type of bugs.

Branches in spells -- you know how and when to use them already :) If
not and/or not sure -- feel free to ask. IRC, PM, MLs were invented
for that, heh.

3. Distribution.

That's about distribution of the system itself. While our ISO is a left
baby, I'd still see the only issue to fix it quickly (until parents are
found) by chroot-image usage with boot ISOs by other Linux distros.
That's the issue, yes, but better than nothing with outdated kernel
and tools. And again we're returning to #1. But there's more work to
come: we need to document better an installation from chroot image (or
resurrect it from our old wiki and bring to modern state).

4. Mirroring.

Thanks to Bor, who updated and fixed many broken upstream urls and
actually initiated the process itself. But the question goes much
deeper.

Epic fail of kernel.org in the previous year presented that our
mirroring system really sucks. To fix this,

first of all we need to increment a number of mirrors we have for
upstream tarballs' backup storage (and keep them for a long time) across
the globe

and secondly create a spell (like smgl-mirrors) or update sorcery's
URLs with recent destinations to kernel.org, perl/python/php/ruby
package databases, sourceforge, freshmeat, berlios mirrors, etc. to
have all metalinks/macrolinks up to date.

Finally, you're always free to choose -- this is an idea of open
source :)

That's all for now, thanks.

-- 
Dont wait to die to find paradise...
--
Cheerz,
Vlad "Stealth" Glagolev

Attachment: pgpS0SmxuFQuO.pgp
Description: PGP signature