[crossfire] (Automated) Client Snapshot Releases

Sun Nov 30 05:06:10 CST 2008

Le samedi 29 novembre 2008, Kevin R. Bulgrien a écrit :
> Non-Linux builds are always hazards.
>
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.

> 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. As I've said, generating proper packages 
from the SVN is not the difficult part of making a release, provided you have 
the matching environment available (Windows to create Win32 packages, OSX for 
the Mac ones, etc).

> > Given the time it would have taken to properly fix those issues - and I'm
> > actually not sure they could have been - and also given that another
> > client was already available as a daily package, daily packaging of the C
> > clients has been abandoned.
>
> Not everyone is satisfied with the current state of affairs, and one of
> these is trying to contribute something positive.
>
I simply exposed why the C client was not part of the public daily packaging 
process anymore. My explanation had nothing to do with being satisfied or not 
with a morale situation. 

> If there is something new released, and if someone cares about non-x86,
> they can deal with and contribute to build and packaging.
>
Not everybody is a developer, or is willing to invest time in learning the 
necessary techniques.

> If no one cares, 
> then... what good reason is there to care about such an ideological issue?
>
Just because nobody steps in to support a given environment doesn't mean 
nobody would be interested to see the game available on those.

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".

> 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.

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.

> > The fact that the 2.x server itself is still a highly moving target, and
> > thus that a release would be very prematurate. To me, it seems that a
> > release, unless marked specifically as "alpha/beta", needs to be
> > relatively stable and finished.
>
> Firstly, this ignores the fact that the "2.x" client is still branch
> compatible many months after 2.x was created, and it has many enhancements
> that should be available to branch players.
>
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.

> In summary, though the arguments presented make it sound reasonable to
> dispense with the idea unattended builds, they do not seem to provide a
> reason to continue to leave a perfectly good client with improvements
> unreleased.
>
I've never commented against making a release of the current C client code. 
I've only commented against doing it as a "2.x client".

> The script is presented primarily because when I have lobbied for release
> previously, one of the reasons given was that it was so difficult to make
> a release. I aimed to remove the possibility of being given that reason 
> again.
>
Let's be clear on this: I do agree that it is difficult to make a proper 
release. But indeed, we obviously disagree on where the difficulty lies. You 
also seem to confuse the notions of "release" and "periodic snapshots". To 
me, both are quite different, and don't have the same quality requirements.

> At this point, to my knowledge, the branch clients have the same 
> instabilities as what is on trunk, but offer fewer options to players.
>
Then why not make a new branch release by taking a snapshot of the current 
trunk content, and number it 1.12 ? To that, I indeed agree.

> I did a lot of work on that client.  I'd like to see it getting put out
> there for people to use.  I think that's easy to understand, and do not
> see why it should be so quickly argued against.
>
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.

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.

-- 

Lauwenmark.
------------
"Drive defensively: buy a tank."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081130/cfa50f93/attachment.pgp 