Public SourceMage Discussion List

[Andraž 'ruskie' Levstik <ruskie AT codemages.net>]

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