[crossfire] Client Snapshot Builds

[Kevin R. Bulgrien]

> Not at all. They are only difficult because they require availability of
> each platform. Or, to formulate it differently: it is hard to build a
> Win32/FreeBSD/Solaris/OSX package without a working installation of
> Win32/FreeBSD/Solaris/OSX.
> 
>> AFAIK, releasing has little to do with breakage.
>>
> What I tried to explain was that it was not a good idea to make a release
> when you don't have the guarantee that it works at least good enough for
> common, daily use.
> 
> That's also why the ailesse daily builds were never advertised as
> "releases", but as "builds" - they don't meet the necessary quality checks
> of a stable release. Their only purpose is to allow non-programmers to
> test them and provide feedback. That's also why the Gridarta page on the
> Crossfire website says "No release yet", despite daily builds having been
> available for months.
> 
> In short: "experimental build != release" by far.

Agreed, it appears the use of the word "release" and "automated" in the
subject is the primary concern.  They need need not be there.

The release procedure mentions nothing about cross-platform checks.
Perhaps it should, but if a releaser checks all the platforms at the
moment, it is undocumented, and I suspect, not done, by looking at
the website client page, so sticking on that point might cause all
releasing to stop.  I have a Sparcstation I could set up, and enough
old hardware for a BSD, but will never have a Mac.
 
>> The more serious breakage is due to incremental development
>> and a failure to release in a timely manner.  Frankly, I see this as a
>> lesser issue than the failure to make current development available
>>
> The current development can easily be made available through a system of
> daily builds, again in the same fashion as Gridarta or JXClient, with the
> caveat that shipping packages for something else than Linux/x86(_64) may
> be made difficult due to lack of a proper testing infrastructure.
> 
>> Further, automated releases were only one possibility mentioned.  The
>> other
>> was for periodic release.  From what has been said in the past, it seems
>> releases are not done because it is difficult.  The script makes it not
>> difficult.
>>
> Frankly, I don't get what would make releases so difficult, from the
> strict package creation side of things.

The releaser said it was difficult, and since he does the releases,
that's what matters.  Its in list history.  In response, I addressed
the issues I understood to be problems.

> Just as a side note, a reminder from the Wiki front page:
> 
> "Crossfire works on:
> - Linux
> - Windows
> - All *BSD?s
> - Mac OSX (Server and clients compile, in testing)"
> 
> So, if we advertise the game as supporting those platforms, then I
> consider it is our duty to ensure that the releases support them.
> Note again that I'm considering "releases" here, not "builds".

I see from the web site that clients of varying versions are there,
demonstrating that we  have not stuck to ideals in the past, and
probably need not be idealistic at this point even if we do try to
improve incrementally.  Debian, and other packaging formats are
also missing, implying some external effort is understood to be
required, but then this is probably approaching the point of
beating on dead horses.

>> Besides, people should be able care less whether some niche group happens
>> to like a different x86 client while the rest of the world explores the
>> cross-platform nirvana demonstrated by the other client.
>>
> I don't think I ever mentioned any kind of "cross-platform nirvana" -
> JXClient has its own share of issues, some being related to portability. I
> don't think I denied you the right of enjoying another client, either.
> 
> My points were that IMHO:
> (1) Package creation on an available platform was not a problem;
> (2) Package creation on a not available platform was a problem;
> (3) C code daily packages were not made public on ailesse due to (2).
> 
> Given that your scripting solution didn't seem to adress (2), I found
> important to underline the issues I encountered with the daily package
> generation process on ailesse.

Got to start somewhere...  thats how most problems are tackled...  You
had a solution, not made public, I did not know about... I had to redo
effort.  Now I have something, but because it is not perfect must we
force the next guy to start from square one?

> Now, you can consider those issues as irrelevant - I've no problem with
> that. But then, it means that the new scripts will not make my task as a
> packager any simpler, making me wondering what purpose they'd then be
> supposed to fullfill.

Many projects do not attempt to package for all platforms but rely on
interested parties to care for that and report issues.  That's not the
same thing as being irrelevent in the purest sense of the word.  I would
like to see cross platform builds, but I don't want to see the project
continue as-is if that is the only reason.  Some of the distribution
packagers believe that packaging is not something a project should attempt
as I have personally gotten grief for that sort of thing.  I happen to be
a bit more in the middle.  I'd hope being on the other extreme did not
retard the projects ability to move forward.

> Then make a 1.12 branch out of that code, and release it under a 1.12
> version, with the added benefit of deprecating the client 1.11 branch,
> ending its support.
> 
> My comment was just about releasing the client code under the "2.x" code,
> and using trunk as the codebase instead of first making a stable branch
> out of it.

Ok, now we're getting somewhere.  I had a similar thought the other day.
 
> No, I'm basically questioning the usefulness of the proposed scripts. In
> which way would they make my life as a packager easier ? So far, I'm
> unsure of the answer, so yes, I'm rather cold to the idea.

Apparently not everyone thinks making packages is easy.  I did not, and
would have not wasted my time making a script if it were as easy as seems
to be implied.  Without further interest, there is obviously no point in
continuing to banter about it between us.  We need to agree to disagree.

> I'm also arguing against releasing anything under the 2.x version mark at
> this stage. Quoting myself again, "it seems that a release, unless marked
> specifically as "alpha/beta", needs to be relatively stable and
> finished.". Is 2.O stable and finished ? no - thus, don't make a 2.0
> release. But again, I see nothing wrong in releasing the client as a
> member of the 1.x family, since this is what we have today, and that it
> works pretty well with the current servers in use.

Thanks for the reply.  It helps show positions are not as far apart
as they initially seemed to be.  I do think the slow release cycles
hurt the project.  I'm not sure people see that.  Since I think that,
some attempt was made to proactively deal with it.  Perhaps the initial
ideas were flawed here and there, but the basic intent still seems
reasonable, and we apparently will continue to disagree on automation
as been something that improves the project because it does not support
all platforms we claim to support.