Bastiaan Jacques wrote:
> I'm proposing that we change our release cycle from six months to three
> months. There are a few reasons why I think this is necessary:
At Cygnus we did GCC releases every 3 months for more platforms than
Gnash even supports... We also had more people focused on the release
process itself. Maybe someday we'll get there, but not any time soon.
Here's my rant on our release process. I often feel then entire thing
gets dumped primarily on me, since much of the process is testing on all
the distributions, and making sure Gnash still builds and runs. Since I
have a bit too much going on as it is, it takes me forever to get
through the process. And because it takes a while, development keeps
going on, which makes it hard to stay stable. I assume this is because I
wrote most of Gnash's configure/build infrastructure. I'm ready to be
done with it to be sure. I will say the other Gnash developers *are* all
very good about bug fixing and other related tasks, but multi platform
and configuration testing is slow and tedious work, and nobody else has
a big interest in doing this.
I see everyone saying "lets have a 3 month release cycle", I'm all for
it too. But I have no interest in being a full time release engineer,
and I spend a huge amount of time doing this as it is. I have
development projects of my own for Gnash/Cygnal I'd rather be focusing
on. So for this to become a reality, I can't be the bottleneck in the
process. I'm willing to finish on the sysadmin and automation side of
things for now, but I'm definitely looking for getting out of the way.
> On the other side, I can see a reason why we'd want to keep the cycle at
> its current length. Namely, releasing costs developer resources. I think
> we can avoid a lot of this cost by the aforementioned streamlining. This
> can be done, to name two examples, by strictly adhering to deadlines
> (I have volunteered for this job) and by automating things. Rob has been
> working on the automation a lot already, by setting up a build farm
> which will do things like automated testsuite runs and like producing
> test builds with various configurations.
Which is why I'm created the build farm. It was very useful during
this last release. I've got the majority of the low level automation
working, and now I'm ready to turn it over to somebody else to do the
higher level stuff that needs to go on top. The build farm still needs
more VM images and hardware, but it's a start.
What's left is:
* Cron job to build Gnash nightly (strk has one already)
** Cron job runs testsuite, outputs results in XML
** XML goes in database of test results
** builds binary tarball (bz2 gz)
** builds binary package (deb, rpm, ipkg, pkg)
** uploads packages to getgnash.org
* Web page of updated build matrix, available packages
* Improve documentation
* Fix packaging code
** BSD
** ipkg
** Improve installation shell script
So anyway, changing to a 3 month cycle is only going to happen if
other people take responsibility for it. I'm glad to help out with build
system hacking, but I'd rather others take over the responsibility for
the releases. In typical free software project style, it's up to *you*
(whoever decides this applies to them) to fix this process and shift us
towards more frequent releases. 3 months comes pretty fast, I'd get
started... :-)
- rob -
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
