Author Topic: Fluffos / POLA  (Read 6220 times)

Offline Andrew

  • Acquaintance
  • *
  • Posts: 12
    • View Profile
Fluffos / POLA
« on: March 16, 2013, 10:05:01 AM »
While it is good to see fixes for Fluffos, I would like to draw attention to http://en.wikipedia.org/wiki/Principle_of_least_astonishment (POLA)

Looking at the diffs for the upcoming 2.27 (under https://github.com/fluffos/fluffos/compare/master...next-2.27) there are changes to:
* move most of the text files out of src
* remove support for make tools other than gmake

I haven't see any discussion about these (which I would rather did not make it into a release) but they do seem to contravene POLA.

Andrew

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #1 on: March 16, 2013, 03:46:59 PM »
You have to be more specific on what exactly do you object and what is the reason. you raise two questions :

* move most of the text files out of src

These files are just moved from src to project root directory (and duplication eliminated),  it is the most common way of storing such files , what is the reason for not doing that?

* remove support for make tools other than gmake

There has been *no support* for tools other than GNU toolchain.  because no one actually test it ( it may still work, but who know what change will break it? and what is the reason for not using GNU toolchain? ) .  I only plan to support GNU toolchain, that's why I find it irritating to have old broken stuff laying around, and I've been doing some cleanup work. I also removed the support to use xlc compiler.

If there is more commit you reject/disapprove, you can either send a pull request/patch or comment on the file  (in github), i'm happy to discuss.

Offline Andrew

  • Acquaintance
  • *
  • Posts: 12
    • View Profile
Re: Fluffos / POLA
« Reply #2 on: March 17, 2013, 10:15:36 AM »
* move most of the text files out of src

These files are just moved from src to project root directory (and duplication eliminated),  it is the most common way of storing such files , what is the reason for not doing that?

It is essentially a cosmetic change that makes comparing against older / external versions of FluffOS more painful. It could have been resolved by having the root README point to src/README etc.

It also has an implied assumption that the packaging will change which is more effort for anyone tracking FluffOS to deal with.

* remove support for make tools other than gmake

There has been *no support* for tools other than GNU toolchain.  because no one actually test it ( it may still work, but who know what change will break it? and what is the reason for not using GNU toolchain? ) .  I only plan to support GNU toolchain, that's why I find it irritating to have old broken stuff laying around, and I've been doing some cleanup work. I also removed the support to use xlc compiler.

If there is more commit you reject/disapprove, you can either send a pull request/patch or comment on the file  (in github), i'm happy to discuss.

There has been no ACTIVE support for anything other than the OS that Discworld runs on (Linux) but patches for other platforms have been accepted. This is not the same thing as no support. If anyone is using a particular OS / compiler and keeping up to date then they are likely to feed the fixes back as well as any other fixes they come up with.

As far as the GNU toolchain goes, it might not be available - not all muds get run on Linux boxes where the admin has root access.

Given the move to using github it seemed that there were likely to be more people involved with maintaining FluffOS which would mean that some consensus on what platforms / toolchains are supported would be needed.
I don't have a problem if you only make changes for the GNU toolchain so long as it does not prevent other toolchains being used and patches for other toolchains will be accepted.
Just because you don't use something does not mean that is broken.

As a datapoint FluffOS 2.24 can be built on Solaris without gmake which this change will break.

Andrew

Offline vorpal

  • Acquaintance
  • *
  • Posts: 14
    • View Profile
Re: Fluffos / POLA
« Reply #3 on: March 17, 2013, 11:51:23 AM »
I'll comment on the README question - I looked at Quixadhal's git history, and noticed a few small issues which we should correct with respect to the text files, perhaps even by reconstructing Quix's git history and rebasing on top of that.

In the old (pre v20) MudOS tarballs, all textfiles except for README are symlinks into the src directory.  Symlinks can be committed into git no problem, so we should do that.  Also, that toplevel README file was actually different from the README in src/.  This got clobbered in Quix's mudos-v20.22 commit.

There are a few other file hierarchy issues such as the location of the "testsuite" directory, which moved from /mudlib/testsuite to /src/testsuite.  This one's more up for debate, though.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #4 on: March 17, 2013, 01:27:40 PM »
It is essentially a cosmetic change that makes comparing against older / external versions of FluffOS more painful. It could have been resolved by having the root README point to src/README etc.

It could be done in a few different ways. Yes

It also has an implied assumption that the packaging will change which is more effort for anyone tracking FluffOS to deal with.

Let me ask you this.  How do you track changes in FluffOS?  Yes if you compare the tar file released by wodan and git directory of next-2.27 ,you will have problems. But to be clearer, your method is wrong! Git already contains entire history, every release as commit. The correct way, and the most easy way is to simply track changes using git.

I don't have a problem if you only make changes for the GNU toolchain so long as it does not prevent other toolchains being used and patches for other toolchains will be accepted.
Just because you don't use something does not mean that is broken.

Your concern is the architectural changes  in build system will no longer support other tool chains, is that right? I'm still confused about what exactly are you objecting. 

If you can no longer "make" on soloaris directly, please send a log or send a patches so I can apply or try to fix it. Whatever makes sense.   It's not like your patch will not be accepted due to it is not Linux.

I don't have solaris so I can't test it, but I think the easiest way is to simply install gnu make on those system if you want to compile future changes.

There is one bug you reminded me, currently everything writes makefile content to GNUMakefile which I think it should write to Makefile instead. So you can just change MAKE=whatever and hope it still reads the content.

Anyway, like I said,  either tell me what has been broken or send me patches, I'm happy to discuss both.  But I don't think our time is worthily spent on meta-discussion about "how to correctly release stuff".

Offline Andrew

  • Acquaintance
  • *
  • Posts: 12
    • View Profile
Re: Fluffos / POLA
« Reply #5 on: March 17, 2013, 03:23:13 PM »
Let me ask you this.  How do you track changes in FluffOS?  Yes if you compare the tar file released by wodan and git directory of next-2.27 ,you will have problems. But to be clearer, your method is wrong! Git already contains entire history, every release as commit. The correct way, and the most easy way is to simply track changes using git.

The method I am using has worked for me for the last 15 years while the git repository has just arrived. I also maintain a version of the driver with my own patches (outside of git) that I want to do comparisons against. At some point, it might be worth adding it to git, but that's not something I am planning to do at the moment.

I like the solution that Vorpal suggested where README is a symlink to src/README.

Your concern is the architectural changes  in build system will no longer support other tool chains, is that right? I'm still confused about what exactly are you objecting. 

If you can no longer "make" on soloaris directly, please send a log or send a patches so I can apply or try to fix it. Whatever makes sense.   It's not like your patch will not be accepted due to it is not Linux.

I don't have solaris so I can't test it, but I think the easiest way is to simply install gnu make on those system if you want to compile future changes.

There is one bug you reminded me, currently everything writes makefile content to GNUMakefile which I think it should write to Makefile instead. So you can just change MAKE=whatever and hope it still reads the content.

Anyway, like I said,  either tell me what has been broken or send me patches, I'm happy to discuss both.  But I don't think our time is worthily spent on meta-discussion about "how to correctly release stuff".

My objection is that the change in https://github.com/fluffos/fluffos/commit/ec89a4efa56882ad6d37565c909cb281859b078e means that systems where earlier versions of FluffOS used to build will no longer build in this latest version.

For instance building 2.26.1 on Solaris 10 with some massaging (remove -m64 and -flto, uncommenting the appropriate OSFLAGS= line) to build it 32 bit and a replacement for the use of MIN in comm.c builds (using make and yacc).
After similiar massaging with 2.27-next (and renaming GNUmakefile to Makefile) just ends with failures due to gmake only functionality.

I think it should be reverted because it is a regression in platform support that makes it much harder to build FluffOS on other platforms.

However I think continuing this is fairly pointless since you have shown no inclination to revert it.

Andrew

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #6 on: March 17, 2013, 05:26:28 PM »
I like the solution that Vorpal suggested where README is a symlink to src/README.

Okay, let's do that then.   I still want to point out,  the *hardness* of such compare can be easily avoided by simply only comparing "*.c" and "*.h" files.

Quote
I think it should be reverted because it is a regression in platform support that makes it much harder to build FluffOS on other platforms.

However I think continuing this is fairly pointless since you have shown no inclination to revert it.

The reason I can't just revert that is because there is more to it, if you read later commits it reworked the build system.  It's not just about one commit , I would need to change all later commit to make sure they still work.

Quote
For instance building 2.26.1 on Solaris 10 with some massaging (remove -m64 and -flto, uncommenting the appropriate OSFLAGS= line) to build it 32 bit and a replacement for the use of MIN in comm.c builds (using make and yacc).
After similiar massaging with 2.27-next (and renaming GNUmakefile to Makefile) just ends with failures due to gmake only functionality.

Can you tell me what is the error then? that's what I wanted to see after all! There is going to be several problem:

1)  you are compile in 32bit  ? I doubt the driver would actually function correctly in such case, has it been before?
2)  you also only have yacc, that's another problem. bison supports some output control flag that yacc don't.
3)  what exactly is failing on GNUMake only feature ?

Offline vorpal

  • Acquaintance
  • *
  • Posts: 14
    • View Profile
Re: Fluffos / POLA
« Reply #7 on: March 17, 2013, 05:42:28 PM »
I like the solution that Vorpal suggested where README is a symlink to src/README.

Okay, let's do that then.

Hang on, that's not what I was suggesting.  I was pointing out an error in Quix's git import.  Take a close look at what happened between tags "mudos-0.9.20" and "mudos-v20.22".  The files /README and /src/README were distinct files before mudos-v20.22, with completely different contents.  As of the "mudos-v20.22" tag, /src/README file got moved to /README, clobbering the /README file which was already there.

Unpack the tarballs here: http://elenia.lpmud.org/mudos/  (Warning - some of these unpack into your current directory, so "tar tf" them first.)  Somewhere in the 0.9 series, most (all but /README) of the text files in "/" were changed to symlinks.  Some of the tarballs have the complete directory structure (/src, /mudlib, /doc), and some are tarballs of the /src directory only.  FluffOS was forked from one of the /src-only tarballs; Quix's git repo restores the full directory structure as was originally intended.  It even includes the long-neglected /doc files.

Offline vorpal

  • Acquaintance
  • *
  • Posts: 14
    • View Profile
Re: Fluffos / POLA
« Reply #8 on: March 17, 2013, 06:01:40 PM »
A few words about multi-platform support, as it relates to the work sunyc is doing.  A few of the changes that sunyc made recently - automation of the unit tests, integration into Travis CI - these are important first steps toward improving the quality of the releases, especially important with the amount of development activity.

I am not familiar with Travis CI and its capabilities (can it build/test on Solaris?)  For there to be any meaningful multiplatform support, the maintainers *need* a way to validate commits, as they are merged, on all of the supported platforms.  If there are publicly available tools for those platforms, then great.  In the absence of that, we'll need somebody with an interest in supporting that platform to contribute toward automated build validation - which will provide the feedback necessary for the maintainers to revert bad commits and send them back for rework.  Without that automated feedback, they're working blind and they WILL break things regardless of how hard they "try".

Offline Andrew

  • Acquaintance
  • *
  • Posts: 12
    • View Profile
Re: Fluffos / POLA
« Reply #9 on: March 17, 2013, 06:32:04 PM »

The reason I can't just revert that is because there is more to it, if you read later commits it reworked the build system.  It's not just about one commit , I would need to change all later commit to make sure they still work.

From a brief inspection, the changes seem to include:
* Add packages/*.o to the object list and removing linking packages.a
* Changing uses of CPP with CC -E
* Using bison instead of yacc with rename/sed steps
* Adding make test target
* Removing support for adding profiling flags (-pg)
* Add -DDEBUG_NON_FATAL
* Correct a uname -s test for Darwin


1)  you are compile in 32bit  ? I doubt the driver would actually function correctly in such case, has it been before?

Given the previous behaviour was to fall back to compile the driver as 32-bit if "gcc -m64" failed that's another regression.

2)  you also only have yacc, that's another problem. bison supports some output control flag that yacc don't.



3)  what exactly is failing on GNUMake only feature ?

The output from make was:
$make
rm -f cc.h
echo "/* this file automatically generated by the Makefile */" > cc.h
echo '#define COMPILER "gcc"' >> cc.h
echo '#define CFLAGS   "--std=c99 -D__USE_FIXED_PROTOTYPES__ -DBSD_COMP -DSunOS_5 -O3 -g -DDEBUG -DDEBUG_NON_FATAL -DDEBUG_MACRO"' >> cc.h
echo '#define OPTIMIZE "-O3"' >> cc.h
echo '#define OBJDIR   "obj"' >> cc.h
gcc --std=c99 -D__USE_FIXED_PROTOTYPES__ -DBSD_COMP -DSunOS_5 -O3 -g -DDEBUG -DDEBUG_NON_FATAL -DDEBUG_MACRO -o obj/edit_source.o -c
gcc: no input files
*** Error code 1
make: Fatal error: Command failed for target `obj/edit_source.o'
$


Offline Andrew

  • Acquaintance
  • *
  • Posts: 12
    • View Profile
Re: Fluffos / POLA
« Reply #10 on: March 17, 2013, 07:43:32 PM »
A few words about multi-platform support, as it relates to the work sunyc is doing.  A few of the changes that sunyc made recently - automation of the unit tests, integration into Travis CI - these are important first steps toward improving the quality of the releases, especially important with the amount of development activity.

I am not familiar with Travis CI and its capabilities (can it build/test on Solaris?)  For there to be any meaningful multiplatform support, the maintainers *need* a way to validate commits, as they are merged, on all of the supported platforms.  If there are publicly available tools for those platforms, then great.  In the absence of that, we'll need somebody with an interest in supporting that platform to contribute toward automated build validation - which will provide the feedback necessary for the maintainers to revert bad commits and send them back for rework.  Without that automated feedback, they're working blind and they WILL break things regardless of how hard they "try".


I found references to Travis CI supporting Ubuntu 12.04 (presumably on 64-bit hardware since that is now the default when building) but nothing else.

Continuous integration is a good thing and I am sure it will help avoid regressions and crashers.

The project has stumbled along without the maintainer(s) explicitly supporting all the possible platforms it can be built on for many years. The maintainer(s) having continuous integration on all the platforms that can be built is not an essential and those who use other platforms are aware that things can break (they can also break on tested platforms too).  Reviewing fixes sent back from these incidents is a good way for maintainers to become more aware of the portability issues.
Another useful exercise would be to build and test both 32 and 64-bit compiles of the driver under Travis CI. 

I find the talk about amount of developer activity slightly worrying - I consider FluffOS to be a fairly mature piece of software (albeit with some warts) where any changes should be bug fixes or extra functionality that does not change / break existing functionality.  Because of this I don't really want to see radical changes or lots of rewrites of known working code (much as it might deserve it) without very good reasons. 

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #11 on: March 17, 2013, 08:23:21 PM »
Let me phrase this way. perhaps what you want is a 2.26.2, or a 2.27, while I am working towards an 3.0 release.

The breakage for Solaris (or other make system without GNU addons)  can be easily avoided, now that I've seen your log, and I am working on that right now, should be a easy fix.

Along the road in the future, I recently went though the old talks about the copyright issues bundled with driver. I actually would like us work towards a goal of making driver GPL complaint by dropping old outdated code and rewrite piece by piece that is needed. Although that is only my own personal dream in a sunday afternoon.  Depends on reality we may or may not want to go there.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #12 on: March 17, 2013, 08:31:05 PM »
Hang on, that's not what I was suggesting.  I was pointing out an error in Quix's git import.  Take a close look at what happened between tags "mudos-0.9.20" and "mudos-v20.22".  The files /README and /src/README were distinct files before mudos-v20.22, with completely different contents.  As of the "mudos-v20.22" tag, /src/README file got moved to /README, clobbering the /README file which was already there.

I see,  do you think we should do a rebase ?  it would unfortunately rewrote all history, but we should do it as early as possible. I guess

Offline vorpal

  • Acquaintance
  • *
  • Posts: 14
    • View Profile
Re: Fluffos / POLA
« Reply #13 on: March 17, 2013, 08:37:33 PM »
Hang on, that's not what I was suggesting.  I was pointing out an error in Quix's git import.  Take a close look at what happened between tags "mudos-0.9.20" and "mudos-v20.22".  The files /README and /src/README were distinct files before mudos-v20.22, with completely different contents.  As of the "mudos-v20.22" tag, /src/README file got moved to /README, clobbering the /README file which was already there.

I see,  do you think we should do a rebase ?  it would unfortunately rewrote all history, but we should do it as early as possible. I guess

Well, since it only affects a few documentation files, I suppose a rebase would be a bit drastic.  It could be fixed in a commit; we're really not missing much in terms of 'historical accuracy'.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Fluffos / POLA
« Reply #14 on: March 17, 2013, 08:45:09 PM »
Well, since it only affects a few documentation files, I suppose a rebase would be a bit drastic.  It could be fixed in a commit; we're really not missing much in terms of 'historical accuracy'.

would you send a pull-request ? :-D   You can ask wodan to apply that and release as 2.26.2 too.