Am 11.06.2011 02:23, schrieb Michal Maruska:
Hello,
I'll meet Michal Maruska at IRC this weekend, and we'll begin merging then.
He said he'll write some mails
to the ML (on what should get higher prio and stuff)
the emails will arrive a bit later, as I was busy all this week. And
being offline for the next 10 days, the
IRC meeting will happen only thereafter. However I git pullled will
try to rebase my work.
No problem.
Lately my thoughts (and my plans for the first email) have been around
how to distribute releases.
I use ubuntu and my personal PPAs (https://launchpad.net/~mmaruska). I
also use gitorious (https://gitorious.org/~mmaruska [1])
as a central repository to synchronize between my workstations.
I release often -- to fix bugs experiment with features -- (not
specifically sawfish), and distribute
through the PPA to a couple of people (by pinning with priority 1001,
so my versions of standard packages are preferred).
But I start to see the point of having the experimental stable branches:
after a while I like to rewrite my git commits into logical branches
merges thereof.
The problem with releasing often is that given from the stats
practically no one uses the release-candidates.
Indeed I was about to roll-out snapshots from 1.8.90 every 2 or 3 weeks
(with all branches merged), to ease testing.
Given by the no of downloads from a stable (say 1.8.0) i'ts RC is only
around 3-10% of downloads.
Devs and Contributors use GIT and there don't seem to be enough
beta-testers around.
So some advertisement on some big site would be a good idea.
Back in Mar 2008 I wrote an article about SF on PL (pro-linux.de) and
they (the readers) where surprised:
Sawfish is still alive? Development restarted??. I guess our problem
is, that we weren't simply of,
we where kicked out of GNOME, thus the no of ppl who read Sawfish is
dead back then is much higher
than the no of ppl you read Sawfish is alive again. For me it was just
an accident. I was looking for more
infos why Sawfish died, and two weeks later I found the Mails from JSH
and Janek.
We need some marketing, too, I guess.
So, I am using this workflow:
1/ code git commit
2/ debuild --rootcmd=fakeroot --no-tgz-check debi
3/ git push to synchronize
3/ after a while, I want to release, so I have this sequence:
git-dch --release
git add debian/changelog; git commit -m release
git-buildpackage --git-tag --git-debian-tag=experimental/%(version)s
debi --debs-dir ../build-area/
git-buildpackage -S debrelease -S --debs-dir=../build-area --dput
somewhere-ppa
(admittely, i have my wrapper mygit-buildpackage which adds the
--git-prebuild=./auto if ./auto exists,
to the invocation of git-buildpackage). could be autogen.sh as well.
This way, I don't store in git various files generated/provided by
automakeco. (config.* ltmain. libtool install-sh etc.)
I just generate them in the ./auto, so that they _are_ in the debian
source package.
ok, next time I will surely be sawfish specific, although what I care
more is the migration from rep to some better Scheme
possibly with JNI compatible interface).
regards, Michal and sorry for telling Chris at the last moment
Chris
notes:
[1] I was planning to answer to Teika's (Not Sawfish) Hand health
and my handy modifier hack with pointing at
my fork extensions to Xorg, but for lack of time
