Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] wondering about the grimoire branches...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] wondering about the grimoire branches...
  • Date: Tue, 30 Mar 2010 11:28:11 +0200

I read the dev meeting log and there it was mentioned that people don't
use/test grimoire branches. I must admit that I'm also not good at using
branches, even for testing purposes.

What I wonder about is the workflow that is expected for a branch tester. I
got the master branch configured as local grimoire... I can test all stuff
happening there easily. Now suppose I want to test some branches, too. Like,
devel-gcc and some fresh xorg.
I could switch my local git grimoire to the gcc branch, cast gcc.... then I
want to test xorg stuff, so I switch to xorg devel branch and figure out what
spells to cast from there (well, it will mostly be xorg sections... plus
perhaps related spells that need fixing...).

Then, I switch back to master... well, that is not pretty. I'm hampering the
workability of things like 'gaze versions' as the grimoire that I cast gcc
and the xorg stuff from is not there anymore. I am mixing up things.

Now, I guess the proper way would be to create a local branch and merge all
the branches one wants to test into one grimoire (plus merging with updates
in master... but not those conflicting with the branch). But that needs some
effort from the tester that might impact its willingness to actually test.
You want things to be easy to testers. They're nearly like users -- you won't
get them to do anything unless it's convenient;-)
And also, when the tester creates a local merged grimoir from several
branches, it is technically testing some derived work, not the original
branch -- there might have been conflicts to resolve, etc.

I see a big problem in the branches being for the whole grimoire. A branch
usually wants to change a small set of spells... and makes a copy of the
whole grimoire for that. Everything else than the spells worked on starts to
age, while the master branch gets new changes. Because of that we see big
update commits to everything but the spells a branch is concerned with to
sync the rest with master, I presume. What really would ease testing and
acceptance of branches for being useful is a method that gets away with the
cruft:

There should be some generation of overlay grimoires that contain just the
spells that a branch is concerned with. Most easy way would be publishing
that as periodic tarballs just like the test grimoire. The crucial point here
is that that way, a tester -- not only core smgl/git hackers! -- can just add
a devel-gcc grimoire on top of its other grimoires and this will just contain
the core build toolchain that needs to be updated to get a new gcc. This
makes it possible to stack several branch grimoires on top of each other,
avoiding conflicting and outdated versions of spells that the branches aren't
actually dealing with.
It should be possible to generate a tarball of only the spells that had
changes since the branch has been created from master (or if there have been
merges, all spells touched by commits that are not also in master), or
shouldn't it?


Alrighty then,

Thomas.


Attachment: signature.asc
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page