Skip to Content.
Sympa Menu

sm-users - [SM-Users] Spell quality checking

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Andraž 'ruskie' Levstik <ruskie AT codemages.net>
  • To: sm-discuss AT lists.ibiblio.org, sm-users AT lists.ibiblio.org
  • Subject: [SM-Users] Spell quality checking
  • Date: Tue, 29 Sep 2009 21:56:58 +0200 (CEST)

Go make yourself some coffee/tea/whatever you like to drink and sit
down. This is quite a post.

Not just the latest gnome update. But various breakages from various
devel/rc/etc... updates.

I believe most of these occur due to our current policy of
"if it casts commit"

I would prefer if we extend this policy with:
"if it runs commit"

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.

My proposed ideas are:

a) cast test - this should also mean cast with older versions of
libs - as in don't cast the lib first then the app - this way it
ensures no force_depends is needed
This should generally be easy, update the app before the lib.

b) cast from a clean install - this would ensure there are no missing
depends - this could probably be automated by prometheus, there are
alternatives to finding missing depends of course. Some are even in
guru tools.

c) runs - does the built thing run, does it work as advertised
i.e.: does vim edit files, save them, open them
This would need to be defined per spell, maybe in a new spell file.
Just launching might miss something critical. If parts can be
automated it would cut down on time needed. But I think delaying an
update for a few hours so that one can use the app/lib for a while
would certainly be beneficial in the long run.

sorcery system-update is not the ultimate solution. Infact I dislike
doing it - one of the things that happened to me while doing it was
that my /etc/resolv.conf file was replaced by a blank one. Another one
is that my system ran out of disk space so I had various source dirs
left around, a few castfs mounts, and deity only knows what half merged
stages were left around.


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.

* complaining that nobody works in branches that are created - this is
not true and also if you see some work feel free to pitch in don't
complain about it.

I ask for comments from everyone including our users. I believe test
should be stable but not absolutely so. There can be an issue or two
around but a bad breakage(i.e. people that are hitting gtk+2 apps
crashing) should not exist in test.

Yes most work happens in the test(master) branch simply because most
things don't need much checking over. But when doing bulk updates a
branch would be preferable with instructions on what to test, how to do
so and so on.

I'll give an example of how I update a few packages:
dovecot - I follow the mailing list, wait for a few days to a week after
each release to see if there are any serious problems, if there
are none I then update, if there are I see if there are patches
to fix it. Then I run that update for a day. If I don't see any
issues I push it if I do I try to solve them.

xorg-server - When I update I check if there are any new options or any
old one that went away, I update the gl_select patch(if needed
to work with the latest release, run it for a day or so,
trying as many different things as I can - example: run GL app,
try to generate a config, etc. I intentionally avoid devel
versions of X(.99/.999/similar odd numbers) because when
they say devel they actually mean devel.

episoder - I try running it with my existing configs, if that fails I
see if something changed by upstream or if it's something
wrong with the app. If it's with the app I don't upgrade,
if it's upstream(i.e. config change) I do.

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.

I'm not saying this is the ideal way, it's just something I do. I
believe we need to improve our Spell QA process else we'll just get more
and more chaotic.

If people are not willing to work this way then we should probably
extend stable releases to a 2 month cycle so that users can report
bugs, issues etc. Instead of those suddenly hitting stable just because
they were not in the short list of tested spells.

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

And simply don't show them. This is how I do it in xorg-server, hides
the stuff that can break and leaves it at the default state.

I have pointed out some issues I feel strongly about and that I believe
would bring more value to our distro. So I ask again. Developers and users
provide constructive feedback on this issue. Don't be shy, don't be
afraid. Speak up.

PS: Now I'll drop off from exhaustion. I think this is the longest mail I
ever wrote.

--
Andraž ruskie Levstik
Source Mage GNU/Linux Games/Xorg grimoire guru
Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/
Geek/Hacker/Tinker

Show them the ropes and soon they've used that rope to build a bridge to ther
future.

Attachment: signature.asc
Description: PGP signature



  • [SM-Users] Spell quality checking, Andraž 'ruskie' Levstik, 09/29/2009

Archive powered by MHonArc 2.6.24.

Top of Page