Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Spell quality checking

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Donald Johnson <ltdonny AT gmail.com>
  • To: Andraž 'ruskie' Levstik <ruskie AT codemages.net>
  • Cc: sm-users AT lists.ibiblio.org, sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Spell quality checking
  • Date: Tue, 29 Sep 2009 16:07:05 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andraž 'ruskie' Levstik wrote:
> This should generally catch most problems. I'm actually amazed I've
> hit bugs with building things as well. People seem to not be aware
> there are things such as: force_depends and sub depends and similar.

Some better and more accessible docs would help with this. However, I
don't know the API well-enough to write it. I think what would be
helpful is spell writers and maintainers sending things that are not
documented or documented well.

For example, make_single isn't in the BUILD (as of this writing)
document of the wiki and I thought it did something completely
different, which means I will now have to go back and possibly correct
and debug spells that I created. I haven't even begun to touch
sub_depends because the docs make me feel like I could screw everything
up. Using the make_single example, why should I ever use it? Should it
actually be used? If not, why not? Et al ad nauseam.

Now, I know that writers and maintainers have their hands already full
with spells. I'm getting fairly burned out when I try and tackle a few
spells and that has made me fall back to updating the documentation
where I could (as my title should have held :)). It's not perfect, and
I can't devote 100% of my time to smgl at the moment, but it brings me
to my next point.

There's a couple of things that would help the documentation along: more
people on documentation review. Possibly encourage the new dev smgl
gets every so often to review what is absolutely confusing, what to
read, etc., or even encourage outside power users to review our docs to
see what in the world is confusing as well. Lunar has pretty fine docs.
They are comprehensive enough to be useful to the user that wants to
submit a patch. Perhaps we could use their documentation (since it is
under the GFDL) to tidy up some of our documentation.

> Another thing I notice is: * complaining about becoming like Debian
> just because we don't have up to the last minute whatever bleeding
> edge release of something. This mentality is bad. We are a source
> distro, debian is not. We can always update to a later version of a
> package, Debian needs to update then build, then package, then
> release.

I don't mind being called Debian(-like). If releasing things slower and
focusing on stability makes smgl that, so it goes.

> What do all these 3 examples have in common?
> a) I run the app for a while(especially if it's a daemon or a more
> complex one. In case of complexity I'll try to use as many
> functions as I can in some time frame).
> b) I read the ChangeLog/commits
> c) I check where applicable for new configure options, new
> dependencies specific versions of them and so on.

This little effort can definitely go a long way, especially if people
keep local git branches and merge in the commits that seem to work A-OK.
It's adding only a little extra work by reading the logs and running the
program that the writer/maintainer would probably have normally.

If anything, this should at the very least apply to content committed
from unofficial patches to either spells themselves or patches to fix
compilation.

> I would prefer if our spells offered various options that upstream
> provides(e.g.: kdeedu4 - marble can be built without KDE - only needs
> Qt) not just what is used most, or be scared of query spam etc.
>
> Query spam can be easily managed - query: Do you want to configure
> some more advanced options or just stick to defaults? y|N

Yeah. I don't mind query spam. If I am doing a new install, there's
going to be a lot of it, but after I install, queries come up so rarely
it's not even trouble to maintain a working system. But I don't agree
with collapsing all non-default features into one query. Only special
occasions such as where it could break a package or that feature can't
or hasn't been tested thoroughly. Although, in the cast of the latter,
the change should probably be reverted before hitting stable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Sender=Donald Johnson

iEYEARECAAYFAkrCMKAACgkQ/YxjcymZYJhJjwCgkbeWgYRBmG2g8JBW5e2/DZgS
IsAAn0t0bHjEz+03NOddcZ60jQIliFQI
=BJAz
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page