Thomas Pani wrote:
> SVN-based ebuilds bound to a particular revision are easy to write.
excellent! right now we are in exactly that situation with
enblend-enfuse: if I am not mistaken 18-July-2008 is the last one to build.
> I think a good idea would be if I provided updated ebuilds along with
> your Windows binaries (i.e. the same revision). A new ebuild every
> week wouldn't be too much work (it's just updating the ebuild version
> in the filename and the revision in-file).
I don't know ebuilds in detail, but if they are like FreeBSD ports can't
you have a configurable parameter? your updated ebuilds would suggest a
default (e.g. right now SVN 3245 for hugin and CVS -d 18-07-2008 for
enblend-enfuse) that the user can override at their responsibility?
Mirroring what the rest of the builders do is a good idea. Mirroring
what *I* do is not. I don't want to be a SPOF
<http://en.wikipedia.org/wiki/Reliability_engineering>
My last published installer is SVN3082, two months ago. I've built a few
newer versions since then (it's an incremental process that is
relatively easy once set up) but there is a significant difference
between building for self-test and building for publishing.
I've had two attempts at going through for publishing in the past two
months but they both did not result in a new installer. I've just
finished the process for publishing with an installer that will be
bundled with the Nodal Ninja (SVN3242 which for all practical use is the
same as SVN3245 aka RC1). For distribution reasons it does not feature
any of the SIFT-based functionalities.
> Do you have any process to determine which is a usable revision?
sort of.
first: it has to build. If it does not, I try to isolate which change
broke the build and ping the developers.
second: I use it. I have a few test cases, though currently they are
scattered on my HDDs. I intended to make a more formal process, but for
now I usually set up a project or two from scratch and see that
everything works as intended. If there are no significant improvements,
I don't release - the installer is stable enough to be useful.
third: I go through the process of cleaning up for a release. This means
going through the different readme files and make sure they are more or
less updated. I've been sloppy on that one with my last installer. the
minimum here is to make the files readable in Windows (CR+LF!) and make
them clickable in Windows explorer (.txt extension). I also clean up for
consistency, i.e. license texts naming conventions, etc.
fourth: I compile the installer (the files are all in SVN, but so far I
am not aware of any other person who has used them, which is bad because
it makes me a SPOF and in a few weeks my first son will be born and I
will have much less time for this).
fifth: I test the installer. Here too, currently it is an ad hoc
process. I intend to set up VMware instances of Windows to test it with
different OS versions and so, but for now it is just the one single
workstation that I have, Windows XP. Previously I was testing also
install on Windows XP x64, but I have wiped that partition from my HDD
since. Currently I run WinXP inside a VMware in Linux about 50% of the
time, and stand alone the rest of the time. I try to test stand alone
before releasing.
sixth: I consider whether to release. There are always risks inherent in
a new release, so the first criteria I consider is whether the release
will improve the user's life or the quality of the feedback that we get
in the bug tracker. As long as the bugs reported in the tracker are
current enough and the pipeline to the developers is full, I see no need
to make a new release. As long as the new build does not improve the
user's life, I don't see a reason to make a new release. this is quite
different from the test builds that are provided by Tom and Guido quite
regularly.
I hope this helps give you insight into my process, and maybe developing
a process of your own. Linux users are different from Windows users, and
you want your process adapted to their needs.
Yuv
|
