[caudium-general] Re: anyone using snapshots?

[bertrand.lupart AT linkeo.com (Bertrand LUPART)]

> > I'd argue some part of bad quality we had were caused by not having
> > snapshots available, leading to less testing by the developers. More
> > specifically, less testing the source code that will actually be
> > released.
> That's certainly true; part of the reason for asking was to see how many
> people were actually using snapshots.
> 
> > Until we have regular stable releases based on delay since the previous
> > release and importance of bugs solved and/or features added, there
> > should be no reason not to provide daily potentially imperfect snapshots
> > since people would have no reason get a bugfix there which isn't in the
> > latest release. This is valid if less stable release is far more
> > promoted to the end user than the snapshots.
> 
> Not sure I follow here... :)

I meant don't get people tempted to get important bugfixes or features
from snapshots by providing them often enought into frequent enought
releases.

> > If someone comes today, and says "hey i can't manage to get wordpress
> > installed on Caudium", then the change could be made and the answer
> > would be: get tonight's snapshot. I think people would like this better
> > than "get current CVS/SVN source code" (and mess up with autoconf).
> true; the downside is that you end up with situations like Pike 7.6.93:
> that's effectively a snapshot with serious problems that ended up having
> wide distribution. I'm not suggesting that would happen, but it is a 
> possibility.

Yeah, i was thinking about this.
The problem here seems there's some kind of "unofficial releases"
available. I don't know the motivation for choosing 7.6.93 which isn't
available on the Pike site anymore, though. Maybe a bug in 7.6.86 the
maintainer wanted to get rid of.

IIRC, the problem was in the package itself, not from Pike 7.6.93. This
particular problem could have occured with any official release.

> I just want to make sure that we understand all sides of a situation 
> before doing something (or continuing to do something, as in this case).
> That way, we can make well informed decisions that have less of a chance
> of causing problems down the road.
> 
> My personal feeling is that we should only have shapshots if we also do
> continuous builds to make sure that snapshots at least meet a certain
> level of quality.
> 
> I've also really liked the idea of "hotfixes": a set of files that can be
> placed in a certain directory in order to get a bugfix without causing all
> kinds of potential compatibility questions. If we had that, a lot of the
> arguments for having shapshots (wrt bugfixes between releases) go away. As
> a former sys admin from the "solaris school", I'm much more comfortable
> applying a hotfix that only changes 2 files than I am upgrading the whole
> server directory.

How does that works exactly? My first feeling is that you have a
collection of patches, each one fixing a particular bug.
I think i'd feel more comfortable trusting the project developpers and
move to a known, consistent and proven brand new version :)

> All that said, some work would need to be done either way to get snapshots
> working with svn, and to fix the existing problems with shapshot building,
> so that'll go into the work queue to be completed at 
> some point.

That's the next point after svn migration.

Roadmap anyone?

-- 
Bertrand LUPART

http://bertrand.gotpike.org/