Re: [fossil-users] Version 1.28 release?

2014-01-16 Thread Stephan Beal 
On Thu, Jan 16, 2014 at 6:06 PM, Ben Collver  wrote:

> On Thu, Jan 16, 2014 at 10:48:06AM -0500, Richard Hipp wrote:
> > So we have a "branch-1.28" which is suppose to be for release.  I'm
> > wondering if anybody is actually using and testing it?
>
> I am using it for some personal projects, but not 60K page views/day.
> No problems here yet.
>


Ditto for http://fossil.wanderinghorse.net

That said, 99% of the time i'm using the trunk, and only remember a very
small handful of times where that caused me any grief (all of it minor and
quickly resolvable).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-16 Thread Ben Collver 
On Thu, Jan 16, 2014 at 10:48:06AM -0500, Richard Hipp wrote:
> So we have a "branch-1.28" which is suppose to be for release.  I'm
> wondering if anybody is actually using and testing it?

I am using it for some personal projects, but not 60K page views/day.
No problems here yet.

Cheers,

-Ben
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-16 Thread Andy Bradford 
Thus said Richard Hipp on Thu, 16 Jan 2014 10:48:06 -0500:

> So we  have a "branch-1.28"  which is suppose  to be for  release. I'm
> wondering if anybody is actually using and testing it?

I've been using it since it was branched, although my limited use cannot
come close to that of fossil-scm.org.

As for testing, I did run make  tests and had similar results as others.
I  mentioned  some  observations  about  the  tests  requiring  a  clean
repository in which to run.

As for when  it is ready... I  suppose we need more  feedback from those
who are running the branch.

Andy
--
TAI64 timestamp: 400052d8079c
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-16 Thread Richard Hipp 
So we have a "branch-1.28" which is suppose to be for release.  I'm
wondering if anybody is actually using and testing it?

Note that the self-hosting Fossil website, as well as most other websites I
control, like SQLite and Tcl/Tk, are running off of trunk and are thus
getting real-world testing of about 60K page-views/day.  Is anybody doing
that level of testing on the branch?

When do we know that the branch is ready to release?


-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-16 Thread Jan Nijtmans 
2014/1/14 Jan Nijtmans :
> And the last one which doesn't affect fossil
> at all because fossil doesn't use fork():
> 
>
> Branch "branch-1.28" currently contains SQLite 3.8.2
> with 5 additional bug-fixes: All the ones mentioned
> above except the last one.

A small status update: Fossil's "branch-1.28"
contains a new SQLite amalgalation now,
constructed from SQLite's "branch-3.8.2".
This SQLite branch contains all bug-fixes
I mentioned, including the 6'th one (which
actually doesn't affect fossil). No bug-fixes
appeared in SQLite trunk after that, so
it appears there is full agreement on
where the most STABLE SQLite version
can be found at this moment:


Some bug-fixes appeared in Fossil's trunk, the most
important ones are collected here by Joe Mistachkin:
 
In my view, there are two more "Nice-To-Haves" which
are well-enough tested (and evaluated) to be included
in the 1.28 release as well. Those are:
   
and:
   
They are not crucial. I'll leave it to Richard's judgement
whether they should be included or not. I'll be a happy
person either way.

Thanks for all feedback so far.

Regards,
Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Andy Bradford 
Thus said Jan Nijtmans on Tue, 14 Jan 2014 10:33:57 +0100:

> And the last one which doesn't affect fossil
> at all because fossil doesn't use fork():
> 

Technically  it does  use fork()  for SSH  sync operations  but I  don't
believe it fits the description in the above mentioned mailing list post
because the forked  process is an SSH process, not  another process with
sqlite  code running  in it  (well,  ok, it  forks SSH  which then  runs
fossil,  but  clearly  the  sqlite  code  running  in  that  process  is
unrelated).

Andy
-- 
TAI64 timestamp: 400052d55469


___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Jan Nijtmans 
2014/1/14 Mark Janssen :
> With that commit, build still fails on sqlite.c:
>
> src/sqlite3.c:34515: warning: implicit declaration of function
> 'winShmMutexHeld'

Should be fixed now in "branch-1.28".  In trunk it should be
fixed as soon as a new SQLite amalgamation appears there.
(Already fixed by Joe in SQLite trunk, I just cherry-picked it)

Regards,
   Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Jan Nijtmans 
2014/1/14 Mark Janssen :
> BTW you are referring to old MinGW in your commit message. I have installed
> mingw using the installer. How do you get a newer version?

Don't use latest MinGW, it doesn't produce a working fossil,
unless you patch MinGW's "dirent.h". See:

After 3 month this MinGW bug is still not fixed. I'm using
MinGW-W64 for my normal builds, although I have a patched
"MinGW" environment too. It might very well be that latest
MinGW still lacks LABEL_SECURITY_INFORMATION,
anyway it doesn't matter anymore.

Regards,
Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Jan Nijtmans 
2014/1/14 Joseph R. Justice :
>(I also note from the timeline that
> the prospective 1.28 does appear to have a release version of SQLite
> embedded.)

Actually, "branch-1.28" doesn't contain a release version of
SQLite either, it contains the most stable version. This is
almost the same, but not 100%. I'll try to explain (my
personal view, but I'm sure I'm not the only one).

The most stable version at 2013-12-06 was SQLite 3.8.2, there is
no question about it. Proof:
  

What does it actually mean, the "most stable SQLite"?
Most people would say, the SQLite version which the
least number of bugs. Well, no-one know how much
bugs SQLite has, we only know how much bugs are
reported and how many are found during testing.

There are 6 known bugs in SQLite 3.8.2 (that I am
aware of), all of them are fixed in SQLite trunk.
Only one of them can cause an exception
while executing certain SQL queries:
  

There are 3 bug-fixes in "shell.c". Since shell.c
is not actually part of SQLite there is actually
no issue here. SQLite trunk's shell.c contains
only bug-fixes, so the "shell.c" from there
is the most stableone. For those who
are interested:




The two remaining are minor. One that only
affects Cygwin:

And the last one which doesn't affect fossil
at all because fossil doesn't use fork():


Branch "branch-1.28" currently contains SQLite 3.8.2
with 5 additional bug-fixes: All the ones mentioned
above except the last one. Of course, this needs
approval from Richard. Any more bug-fixes that
should go in the branch? Any bug-fixes that I missed?

Thank you very much for your attention!

Regards,
  Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Mark Janssen 
On Tue, Jan 14, 2014 at 9:36 AM, Jan Nijtmans wrote:

> 2014/1/13 Mark Janssen :
> > I am not sure if this is an issue with my MinGW install, but latest trunk
> > fails to build on MinGW. I think it's useful if the official release can
> > also be built on MinGW.
>
> 
>
> Thanks!
>
>   Jan Nijtmans
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

With that commit, build still fails on sqlite.c:

src/sqlite3.c:34515: warning: implicit declaration of function
'winShmMutexHeld'

This function is only defined with -DSQLITE_DEBUG but used without ifdef in
winShmPurge. There are many other issues with building without
-DSQLITE_DEBUG. I am not sure if the proper fix is to define this in the
Makefile or to build without DEBUG.

Defining -DSQLITE_DEBUG gives a warning about %lld:

src/sqlite3.c:5: warning: unknown conversion type character 'l' in
format
src/sqlite3.c:5: warning: too many arguments for format
src/sqlite3.c:7: warning: unknown conversion type character 'l' in
format
src/sqlite3.c:7: warning: too many arguments for format


Mark

BTW you are referring to old MinGW in your commit message. I have installed
mingw using the installer. How do you get a newer version?
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-14 Thread Jan Nijtmans 
2014/1/13 Mark Janssen :
> I am not sure if this is an issue with my MinGW install, but latest trunk
> fails to build on MinGW. I think it's useful if the official release can
> also be built on MinGW.



Thanks!

  Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-13 Thread Joseph R. Justice 
On Thu, Jan 9, 2014 at 8:20 AM, Richard Hipp  wrote:

It has been a few months since the last official release of Fossil.  I
> wonder if we should consider publishing trunk as the official version 1.28?
>

I realize I am responding to this a little late, but, hey, as a
non-code-contributing blowhard, why should I let a little thing like that
stop me?  (*cough*).  More seriously, this response is in light of all
messages on this thread (at least, according to gmail) through Mark
Jannsen's of Mon, Jan 13, 2014 at 5:17 PM (I don't know if that's my local
time, or his, or what).



(1) I think that, if the Fossil devs wish to make a release version of
Fossil incorporating a non-release (e.g. "development", for some value of
the word development) version of SQLite included as an embedded code copy,
then that is fully their right to do so.  They have the right to ship
Fossil source code with whatever they wish to ship it with.  (And again the
right to support using Fossil *only* with whatever version of SQLite they
wish to support it with!)

Moreover, I *am* sympathetic to Dr. Hipp's desire for Fossil, as used by
real end users in the field, to be used with a non-release version of
SQLite, so as to better test SQLite before a release version of *it* is
cut.  I can understand his position, see things from his POV as a developer.

However, I can also understand, and honestly agree with, the position of
many end users and sysadmins that they do not want a "release" version of
Fossil to make use of a non-release version of SQLite, and the position of
packagers of Fossil that they do not want to have to support use with
non-release versions of SQLite.  No matter *what* Dr. Hipp says about the
stability and safety even of development versions of SQLite (at least, of
tagged development versions), and I am quite willing to take his word for
this mind you, the typical end-user has been taught that anything labeled
"alpha", "beta", etc is not to be trusted with precious or irreplaceable
data.  (Much like, these days, many people feel the same way about any
software with a release version ending in ".0", e.g. "6.0", "7.0", etc.)
And, unfortunately, the Fossil upstream devs are not in a position to force
end-users to use or packagers to package software they are uncomfortable
with -- the end-users and packagers can always vote with their feet.



(2) Given (1), I fully expect that the packagers of Fossil for FOSS
Unix/Linux distributions will *not* package it to make use of any latest
trunk / development version of SQLite, but will instead only package it to
use and depend on a stable release version.  (Whether this is whatever code
is shipped embedded with Fossil, or whether it's whatever version of SQLite
they choose to ship with the distribution they are working on, is up to
each individual packager of course.)

I see that, at least as of the moment I write this, that the prospective
Fossil 1.28 appears to still have the capability for
--disable-internal-sqlite so that even if it were shipped with an embedded
code copy of a non-release version of SQLite a packagers could choose to
use the system provided version of SQLite.  (I also note from the timeline
that the prospective 1.28 does appear to have a release version of SQLite
embedded.)  However, if --disable-internal-sqlite were removed, and if the
embedded code copy of SQLite was a non-release version, I'd be willing to
bet money (a small amount anyway) that the vast majority of (if not all)
packagers would rip that out and use a stable version of SQLite instead in
their package as distributed by their distribution.  (Which, after all, is
*their* right, they only have to support for their end users what *they*,
the packagers, want to support, and not what the Fossil upstream devs wish
to support.  The upstream devs do not have to assist the packagers in this,
of course.)



(3) I have a proposal to try to accommodate both the desires of packagers
and end-users of release versions of Fossil to depend only on release
versions of SQLite, *and* Dr. Hipp's desire for users to use Fossil with a
recent (tho perhaps not heavily-bleeding-edge) non-release version of
SQLite so as to get better testing of SQLite in the wild.  However, I'll
suggest that proposal in a different message.



(4) I see it is planned that Fossil 1.28, as distributed by Fossil
upstream, will require a minimum version of SQLite 3.8.2 per Check-in
[f96162b06b] for branch-1.28.  Fair enough.  Distribution packagers, if
they need Fossil 1.28 to work using older versions of SQLite, will have to
make the appropriate patches; if Fossil upstream does not want to support /
accept those patches, they don't have to.

I think it might be a good idea to also do a _compile-time_ check to insure
SQLite is at the required minimum at time of compilation; I assume this is
feasible to do.

And, of course, this upgraded requirement should all be documented in the
release notes.



(5) Re the performance issue related to W

Re: [fossil-users] Version 1.28 release?

2014-01-13 Thread Mark Janssen 
On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp  wrote:

> It has been a few months since the last official release of Fossil.  I
> wonder if we should consider publishing trunk as the official version 1.28?
>
> --
> D. Richard Hipp
> [email protected]
>
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
I am not sure if this is an issue with my MinGW install, but latest trunk
fails to build on MinGW. I think it's useful if the official release can
also be built on MinGW.

Error is (using make -f win/Makefile.mingw):

src/winfile.c: In function 'win32_access':
src/winfile.c:117: error: 'LABEL_SECURITY_INFORMATION' undeclared (first
use in
this function)
src/winfile.c:117: error: (Each undeclared identifier is reported only once
src/winfile.c:117: error: for each function it appears in.)
make: *** [wbld/winfile.o] Error 1
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Richard Hipp 
On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans wrote:

> 2014/1/11 Richard Hipp :
> > I don't think this should hinder the release.
>
> That's great news. So the valgrind error in the /tar page and
> the two failing test-cases (which simply could be disabled) are
> the only things which should be handled? I wouldn't know
> anything else. Thanks!
>

The valgrind error in /tar has now been fixed on trunk.  (It was utterly
harmless and so it is not necessary to merge the fix into the 1.28 branch.)

I'm currently chasing another valgrind error in the diff-er.


>
> Regards,
>  Jan Nijtmans
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Eric Rubin-Smith 
I have a request.  Can you guys do the official builds SSL-enabled?


On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans wrote:

> 2014/1/11 Richard Hipp :
> > I don't think this should hinder the release.
>
> That's great news. So the valgrind error in the /tar page and
> the two failing test-cases (which simply could be disabled) are
> the only things which should be handled? I wouldn't know
> anything else. Thanks!
>
> Regards,
>  Jan Nijtmans
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Jan Nijtmans 
2014/1/11 Richard Hipp :
> I don't think this should hinder the release.

That's great news. So the valgrind error in the /tar page and
the two failing test-cases (which simply could be disabled) are
the only things which should be handled? I wouldn't know
anything else. Thanks!

Regards,
 Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Richard Hipp 
On Sat, Jan 11, 2014 at 9:31 AM, Richard Hipp  wrote:

>
>
> I just now ran the valgrind test script, and there are issues.  There is a
> performance issue in timeline which seems to be related to Unhide.
>

The performance problem only comes up with WITHOUT ROWID tables are used
(which happens only if you run "fossil test-without-rowid" on the
repository to modify the schema.)  It appears to be some problem in the
SQLite query planner related to WITHOUT ROWID.  Since nobody (besides me)
uses WITHOUT ROWID repositories, I don't think this should hinder the
release.
-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Richard Hipp 
On Sat, Jan 11, 2014 at 6:21 AM, Stephan Beal  wrote:

> On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp  wrote:
>
>> It has been a few months since the last official release of Fossil.  I
>> wonder if we should consider publishing trunk as the official version 1.28?
>>
>
> i'm a bit late to the party (been off with a back injury since New Year's
> Eve), and don't really want to wade through the near-30 responses because
> sitting up on the PC is still very uncomfortable, so i'll just ask: is
> there still a need to run the current trunk through valgrind (or similar
> testing) for the release? i have x64 Mint Linux here i could run it
> through, but won't do so if the release is already on its way out the door.
>
>
I just now ran the valgrind test script, and there are issues.  There is a
performance issue in timeline which seems to be related to Unhide.  And
there is a valgrind error (jump based on uninitialized memory) in the /tar
page.  Those of the problems I've seen so far.  Continuing to
investigate


-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-11 Thread Stephan Beal 
On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp  wrote:

> It has been a few months since the last official release of Fossil.  I
> wonder if we should consider publishing trunk as the official version 1.28?
>

i'm a bit late to the party (been off with a back injury since New Year's
Eve), and don't really want to wade through the near-30 responses because
sitting up on the PC is still very uncomfortable, so i'll just ask: is
there still a need to run the current trunk through valgrind (or similar
testing) for the release? i have x64 Mint Linux here i could run it
through, but won't do so if the release is already on its way out the door.

:-?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Andy Bradford 
Thus said Sergei Gavrikov on Fri, 10 Jan 2014 19:56:54 +0300:

>   * Failures: ... th1-setting-5 th1-setting-6

These two failures appear to be  happening because they expect to find a
setting (autosync  == 1),  but find  something else.  I believe  this is
because they operate  on the current fossil repository which  may or may
not have  the settings that  were originally  present when the  test was
drafted. This means that the test  is not operating on a cleanly created
fossil  repository. Given  that  we  cannot know  what  state any  given
repository is in,  you probably need to create a  new repository and run
the tests from there.

Something like:

FDIR=/path/to/fossil
FOSSIL=$FDIR/fossil
$FOSSIL new /tmp/test.fossil
mkdir /tmp/test; cd /tmp/test; $FOSSIL open /tmp/test.fossil
tclsh $FDIR/test/tester.tcl $FOSSIL

Or  make a  new clone  of fossil  when building/testing  and use  ``make
test'' within that directory. Also, main.mk has this advisory:

# WARNING. DANGER. Running the test suite modifies the repository the
# build is done from, i.e. the checkout belongs to. Do not sync/push
# the repository after running the tests.

In  the future,  perhaps  the tests  need  to be  modified  to create  a
new  test.fossil  from which  to  run  the  tests.  I cannot  tell  what
modifications  might have  been  made to  my clone  of  fossil, but  the
warning seems pretty dire---I wonder if that means I can no longer sync?

Andy
-- 
TAI64 timestamp: 400052d0bba0


___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Martin Gagnon 
On Thu, Jan 09, 2014 at 05:25:04PM +0100, Jan Nijtmans wrote:

[snip]

> I compiled/ran it on Cygwin64, and "make test" ended with:
> * Final result: 2 errors out of 18914 tests
> * Failures: merge-utf-24-23 merge-utf-24-32
> 
[snip]

Same thing here on OpenBSD 5.3 amd64...

I've also made some real world test including the rebuild and
test-integrity on few repos..

-- 
Martin G.
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Sergei Gavrikov 
  ../configure --quiet&&make -s test|sed -ne '/Final result:/,$p'
  Cannot run this test within an open checkout
  Cannot run this test within an open checkout
  Cannot run this test within an open checkout
  * Final result: 2 errors out of 18915 tests
  * Failures: merge-utf-24-23 merge-utf-24-32

  cp ../manifest* .&&fossil close&& mv manifest* ..&&make -s test|sed -ne 
'/Final result:/,$p'
  * Final result: 27 errors out of 18957 tests
  * Failures: merge-utf-24-23 merge-utf-24-32 merge5-10 merge5-50 merge5-72 
merge5-90 merge5-91 merge5-100 merge5-101 merge5-102 merge5-110 merge5-120 
merge5-121 merge5-122 merge5-123 merge5-130 merge5-131 merge5-132 merge5-133 
merge5-134 merge5-135 merge5-136 merge5-140 merge5-141 merge5-142 th1-setting-5 
th1-setting-6

  uname -a
  Linux ** 3.2.0-56-generic #86-Ubuntu SMP Wed Oct 23 17:31:43 UTC 2013 
i686 i686 i386 GNU/Linux

Sergei
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Remigiusz Modrzejewski 

On Jan 10, 2014, at 15:29 , Richard Hipp wrote:

> Thank you.  But those antique test cases don't really matter that much.
> (The test failures you are seeing are likely due to problems in the tests
> themselves, not problems in Fossil, though we will verify this prior to
> release.)

Well, an error in a test is still an error to fix.

> If you want some specific command to run in order to validate Fossil,
> please try these:
> 
> fossil all rebuild
> fossil all test-integrity
> 
> Let me know if either of these commands gives problems for any of your
> repositories.  Thanks.

Both worked perfectly.
If I happen onto any real-world error, I will not neglect to cry out loud ;)


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Richard Hipp 
Thank you.  But those antique test cases don't really matter that much.
(The test failures you are seeing are likely due to problems in the tests
themselves, not problems in Fossil, though we will verify this prior to
release.)

I'm really interested in knowing whether or not the latest Fossil is
working well for you in your daily activities and if you know of any bugs
or problems with the latest Fossil that need to be addressed before we
release.

If you want some specific command to run in order to validate Fossil,
please try these:

 fossil all rebuild
 fossil all test-integrity

Let me know if either of these commands gives problems for any of your
repositories.  Thanks.


On Fri, Jan 10, 2014 at 9:23 AM, Remigiusz Modrzejewski
wrote:

>
> On Jan 10, 2014, at 13:30 , Michai Ramakers wrote:
>
> > * End of utf: 2 errors so far **
> > * Final result: 2 errors out of 18915 tests
> > * Failures: merge-utf-24-23 merge-utf-24-32
>
> The same tests are failing on my machine:
> $ uname -a
> Darwin pc6.home 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41
> PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
> $ ./fossil version
> This is fossil version 1.28 [1f10199a09] 2014-01-09 21:12:11 UTC
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Remigiusz Modrzejewski 

On Jan 10, 2014, at 13:30 , Michai Ramakers wrote:

> * End of utf: 2 errors so far **
> * Final result: 2 errors out of 18915 tests
> * Failures: merge-utf-24-23 merge-utf-24-32

The same tests are failing on my machine:
$ uname -a
Darwin pc6.home 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 
2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
$ ./fossil version
This is fossil version 1.28 [1f10199a09] 2014-01-09 21:12:11 UTC

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Michai Ramakers 
On 10 January 2014 13:25, Michai Ramakers  wrote:
>> On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote:
>>
>>Everybody:  Please download, compile, and test the branch above.  If there
>>are no issues reported, it will become the official 1.28 release.
>
> for my info, when you say 'please test', do you mean 'run the
> test-suite from the build and report errors' or 'try to use it in
> practice' (or both)? I always do the latter; this is the first time I
> even run the test-suite.

fwiw:

* End of utf: 2 errors so far **
* Final result: 2 errors out of 18915 tests
* Failures: merge-utf-24-23 merge-utf-24-32
michai@lime:/tmp/f/f$ uname -a
NetBSD lime.LAN 6.0.1 NetBSD 6.0.1 (GENERIC) amd64
michai@lime:/tmp/f/f$ ./fossil version
This is fossil version 1.28 [6e7e8fbe01] 2014-01-09 21:00:38 UTC

(These are the same errors Jan Nijtmans reported in
http://www.mail-archive.com/[email protected]/msg14301.html)

Michai
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Michai Ramakers 
> On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote:
>
>Everybody:  Please download, compile, and test the branch above.  If there
>are no issues reported, it will become the official 1.28 release.

for my info, when you say 'please test', do you mean 'run the
test-suite from the build and report errors' or 'try to use it in
practice' (or both)? I always do the latter; this is the first time I
even run the test-suite.

Michai
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Martin S. Weber 
more info: test-out @ http://phaeton.sdf-eu.org/fossil-1f10199a09724a50-test-out

-M
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-10 Thread Martin S. Weber 
On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote:
> On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans wrote:
> 
> > 2014/1/9 Richard Hipp :
> > > Jan - would you like to start the "branch-1.28" containing the SQLite
> > 3.8.2
> > > release?
> >
> > 
> >
> 
> Jan: tnx
> 
> Everybody:  Please download, compile, and test the branch above.  If there
> are no issues reported, it will become the official 1.28 release.
> 

* Final result: 27 errors out of 18957 tests
* Failures: merge-utf-24-23 merge-utf-24-32 merge5-10 merge5-50 merge5-72 
merge5-90 merge5-91 merge5-100 merge5-101 merge5-102 merge5-110 merge5-120 
merge5-121 merge5-122 merge5-123 merge5-130 merge5-131 merge5-132 merge5-133 
merge5-134 merge5-135 merge5-136 merge5-140 merge5-141 merge5-142 th1-setting-5 
th1-setting-6

on Linux 3.12.6-1-ARCH x86_64
with gcc version 4.8.2 20131219
from fossil 1f10199a09724a50 (1.28 branch tip)

Side note: failing tests do not print info on stderr (it all goes to stdout 
from a 'make test' invocation POV)
Being able to run make test > /dev/null 2> errs && rm -f errs || ${PAGER:-more} 
errs would be nice ;)

-M
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Oliver Friedrich 



Am 09.01.2014 17:52, schrieb Remigiusz Modrzejewski:
You do realize that "alpha" and "beta" are just words? With different 
quality assurance procedures in different projects, trying to use them 
as a gauge of anything else than releaser intent is misleading.

Well, can I come in here?

Maybe alpha and beta are just words, but they are used for a reason. The 
reason is, that the software in these states is not fully tested and not 
to be considered stable. Therefore the software should not under any 
circumstances be used in productive environment.


So please, if anyone is going to give a stable release, do not use alpha 
or beta dependencies on it, because that makes your software alpha or 
beta for a reason. There is nothing that tells me, if I'm using a stable 
release of fossil, if my repository is getting fucked up by a feature 
from the alpha/beta sqlite.


Maybe sqlite has a very very good QA and the software is extremly 
stable, but even the own developers do not trust the version as stable - 
so why should we?


regards,

Oliver

___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Gour 
On Thu, 9 Jan 2014 15:35:06 -0500
Richard Hipp  wrote:

> The fact that you feel this way (and that you probably represent the
> views of many others who haven't bother to comment) shows that Jan is
> correct, and that we really need to back up to the last version of
> SQLite that is deemed "stable" for the release.

I trust your QA of Fossil, but, at the same time, wishing that Fossil
become spread more widely, believe it's better not to be 'shipped' with
alpha-labelled SQLite code.


Sincerely,
Gour


___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Remigiusz Modrzejewski 

On Jan 9, 2014, at 21:38 , Remigiusz Modrzejewski wrote:

>> [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter.  All 
>> that means is that if there ever is a data loss, it will take some time to 
>> propagate among the copies, during which time I *may* catch it in time to 
>> recover, before the last copy gets tainted.
> 
> The fact that Fossil is sort of write-only should.

What I meant is obviously append-only.

> By design Fossil does not allow changing (thus destroying) any historical 
> records.
> The only unwanted thing that can conceivably propagate is your CC number in a 
> test file.
> If you are concerned by new software errors eating your code, simply don't 
> update your central location.
> Fossil can easily interoperate in the distance of many versions.
> 
> Kind regards,
> Remigiusz Modrzejewski

___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Ruediger Haertel 
Am Donnerstag, 9. Januar 2014, 13:15:30 schrieb Warren Young:
> On 1/9/2014 07:31, Richard Hipp wrote:
> > But I want Fossil to follow the latest SQLite alphas,
> 
> So run sqlite.org with Fossil + SQLite alpha.  Everyone is free to run
> Fossil in any configuration they like.
> 
> Please don't ask the rest of the Fossil user community to alpha-test
> SQLite for you, using their precious source archives as cannon fodder.

+1


> 
> > SQLite alphas are more robust that "stables" of most other software
> > projects.
> Are you asserting that no data-destroying bugs have ever appeared in a
> SQLite alpha?
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Remigiusz Modrzejewski 

On Jan 9, 2014, at 21:28 , Warren Young wrote:

> On 1/9/2014 13:17, Richard Hipp wrote:
>> 
>>SQLite alphas are more robust that "stables" of most other
>>software projects.
>> 
>> 
>>Are you asserting that no data-destroying bugs have ever appeared in a
>>SQLite alpha?
>> 
>> 
>> 
>> Yes, I am.  Are you aware of any that I missed?
> 
> I'll take you at your word.  I'm not going to go trawl the SQLite changelog 
> to try and prove you wrong.
> 
> I'm just uncomfortable being conscripted into someone else's alpha testing 
> program, especially when that test involves my work product, purposely stored 
> in a central location[*] for archival purposes.

Exactly my point about message sent by the "alpha" word.

> [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter.  All 
> that means is that if there ever is a data loss, it will take some time to 
> propagate among the copies, during which time I *may* catch it in time to 
> recover, before the last copy gets tainted.

The fact that Fossil is sort of write-only should.
By design Fossil does not allow changing (thus destroying) any historical 
records.
The only unwanted thing that can conceivably propagate is your CC number in a 
test file.
If you are concerned by new software errors eating your code, simply don't 
update your central location.
Fossil can easily interoperate in the distance of many versions.

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 3:28 PM, Warren Young  wrote:

>
> I'm just uncomfortable being conscripted into someone else's alpha testing
> program, especially when that test involves my work product, purposely
> stored in a central location[*] for archival purposes.
>


The fact that you feel this way (and that you probably represent the views
of many others who haven't bother to comment) shows that Jan is correct,
and that we really need to back up to the last version of SQLite that is
deemed "stable" for the release.

-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Warren Young 

On 1/9/2014 13:17, Richard Hipp wrote:


SQLite alphas are more robust that "stables" of most other
software projects.


Are you asserting that no data-destroying bugs have ever appeared in a
SQLite alpha?



Yes, I am.  Are you aware of any that I missed?


I'll take you at your word.  I'm not going to go trawl the SQLite 
changelog to try and prove you wrong.


I'm just uncomfortable being conscripted into someone else's alpha 
testing program, especially when that test involves my work product, 
purposely stored in a central location[*] for archival purposes.


I have no problem with you asking people to volunteer for such a test.


[*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. 
 All that means is that if there ever is a data loss, it will take some 
time to propagate among the copies, during which time I *may* catch it 
in time to recover, before the last copy gets tainted.

___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 3:15 PM, Warren Young  wrote:

>
>
> SQLite alphas are more robust that "stables" of most other software
>> projects.
>>
>
> Are you asserting that no data-destroying bugs have ever appeared in a
> SQLite alpha?
>


Yes, I am.  Are you aware of any that I missed?

-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Warren Young 

On 1/9/2014 07:31, Richard Hipp wrote:


But I want Fossil to follow the latest SQLite alphas,


So run sqlite.org with Fossil + SQLite alpha.  Everyone is free to run
Fossil in any configuration they like.

Please don't ask the rest of the Fossil user community to alpha-test
SQLite for you, using their precious source archives as cannon fodder.


SQLite alphas are more robust that "stables" of most other software projects.


Are you asserting that no data-destroying bugs have ever appeared in a
SQLite alpha?
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread sky5walk 
A while back when considering Fossil, I read that 'any' database could have
been chosen in its design. This thread seems to contradict Fossil's
published design theme?

http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki
Thoughts On The Design Of The Fossil DVCS:
"We claim that Fossil is not based on SQLite at all and that Fossil is not
based on a distributed NoSQL database because Fossil is a distributed NoSQL
database."

"Fossil Is A NoSQL Database
We begin with the first question: Fossil is not based on a distributed
NoSQL database because Fossil *is* a distributed NoSQL database. Fossil is
*not* based on SQLite. The current implementation of Fossil uses SQLite as
a local store for the content of the distributed database and as a cache
for meta-information about the distributed database that is precomputed for
quick and easy presentation. But the use of SQLite in this role is an
implementation detail and is not fundamental to the design. Some future
version of Fossil might do away with SQLite and substitute a pile-of-files
or a key/value database in place of SQLite. (Actually, that is very
unlikely to happen since SQLite works amazingly well in its current role,
but the point is that omitting SQLite from Fossil is a theoretical
possibility.)"

I treat Fossil as a standalone and critical app and believe it deserves
higher standing than a test bed for SQLite.

Thanks for Fossil and SQLite!


On Thu, Jan 9, 2014 at 11:52 AM, Remigiusz Modrzejewski
wrote:

>
> On Jan 9, 2014, at 16:35 , [email protected] wrote:
>
> > Took time to reply, cause I had to clean the coffee I spit up!
> > A released application should be considered stable and a conservative
> view
> > would say its libs should not contain alphas or betas.
> > The ease of compiling a bleeding edge Fossil.exe is already in place for
> > those wishing to gain the latest features in trunk.
>
> You do realize that "alpha" and "beta" are just words?
> With different quality assurance procedures in different projects,
> trying to use them as a gauge of anything else than releaser intent is
> misleading.
> SQLite QA is so impressive that some may be pretty comfortable with having
> any version,
> provided it has passed a full test suite, included in their systems.
>
> The problem here is the message sent by the word "alpha".
> What it usually means is "I just wrote it, hope it will not explode in
> your face, but no warranties".
> Therefore if we want to say "Fossil is rock-solid", we can't say "it uses
> alpha libs",
> just to avoid the confusion, no matter the actual quality.
>
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Remigiusz Modrzejewski 

On Jan 9, 2014, at 16:35 , [email protected] wrote:

> Took time to reply, cause I had to clean the coffee I spit up!
> A released application should be considered stable and a conservative view
> would say its libs should not contain alphas or betas.
> The ease of compiling a bleeding edge Fossil.exe is already in place for
> those wishing to gain the latest features in trunk.

You do realize that "alpha" and "beta" are just words?
With different quality assurance procedures in different projects,
trying to use them as a gauge of anything else than releaser intent is 
misleading.
SQLite QA is so impressive that some may be pretty comfortable with having any 
version,
provided it has passed a full test suite, included in their systems.

The problem here is the message sent by the word "alpha".
What it usually means is "I just wrote it, hope it will not explode in your 
face, but no warranties".
Therefore if we want to say "Fossil is rock-solid", we can't say "it uses alpha 
libs",
just to avoid the confusion, no matter the actual quality.


Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Jan Nijtmans 
2014/1/9 Richard Hipp :
> Jan: tnx

Your're welcome!

> Everybody:  Please download, compile, and test the branch above.  If there
> are no issues reported, it will become the official 1.28 release.

I compiled/ran it on Cygwin64, and "make test" ended with:
* Final result: 2 errors out of 18914 tests
* Failures: merge-utf-24-23 merge-utf-24-32

This is no big deal: Fossil 1.26 and 1.27 had the same
failures, I am convinced that those 2 are test-case errors.

Regards,
 Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread j. van den hoff 

On Thu, 09 Jan 2014 16:55:17 +0100, Richard Hipp  wrote:


A consensus seems to be emerging that perception is more important that
truth and hence the latest "release" of SQLite should be in the Fossil


more important than truth? I think nobody said so and I would not agree to  
that "consensus".


the question rather seems
whether you care for adoption of `fossil' -- in which case, indeed,  
perception
of the potential new users is a non-negligible factor. personally, I would  
like
to see an increase of the user base and broader acceptance of fossil,  
especially since `git' (with its tons

of gotchas making it ill fit for "human-sized" projects in my view)
increasingly seems to be the only (recognized) game in town.


release, rather than the latest trunk version of SQLite.  I think that is
silly, but I will yield to the consensus.

Jan - would you like to start the "branch-1.28" containing the SQLite  
3.8.2

release?

I'll continue to keep the latest SQLite trunk on the Fossil trunk, and  
run

the Fossil trunk on important websites like http://www.sqlite.org/,
http://www.fossil-scm.org/, and http://core.tcl.tk/.  That will be
sufficient testing.






--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans wrote:

> 2014/1/9 Richard Hipp :
> > Jan - would you like to start the "branch-1.28" containing the SQLite
> 3.8.2
> > release?
>
> 
>

Jan: tnx

Everybody:  Please download, compile, and test the branch above.  If there
are no issues reported, it will become the official 1.28 release.


-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Jan Nijtmans 
2014/1/9 Richard Hipp :
> Jan - would you like to start the "branch-1.28" containing the SQLite 3.8.2
> release?



Regards,
Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
A consensus seems to be emerging that perception is more important that
truth and hence the latest "release" of SQLite should be in the Fossil
release, rather than the latest trunk version of SQLite.  I think that is
silly, but I will yield to the consensus.

Jan - would you like to start the "branch-1.28" containing the SQLite 3.8.2
release?

I'll continue to keep the latest SQLite trunk on the Fossil trunk, and run
the Fossil trunk on important websites like http://www.sqlite.org/,
http://www.fossil-scm.org/, and http://core.tcl.tk/.  That will be
sufficient testing.



-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread j. van den hoff 
On Thu, 09 Jan 2014 16:26:35 +0100, Ramey, Christopher  
 wrote:



On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp  wrote:



On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski <
[email protected]> wrote:



On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:

>> But I want Fossil to follow the latest SQLite alphas, not the latest
SQLite
>> stables.  That's the whole point:  Fossil supports SQLite as a test
>> platform.  SQLite stable has already been thoroughly vetted and  
tested

and
>> there is little point in testing it further.  I want Fossil to run
with the
>> latest SQLite on trunk to smoke out bugs early.
>
> ...but fossil in itself is a pretty awesome piece of software, that's
expected
> by its users to be stable -- at least for releases.

I second this view, Fossil is definitely valuable on its own merit.
As such, its stable versions should not contain alpha-quality code from
other projects.



SQLite alphas are more robust that "stables" of most other software
projects.



I'd be more concerned about the appearance of using a SQLite alpha in
Fossil. People have to have a great deal of faith in the quality and
stability of their VCS - using anything branded "alpha" even on the
insistence that it's better than most other stables could have a damaging
effect on Fossil's reputation.


+1

were I not already using fossil in the first please, reading
that the considered DVCS uses alpha state software for it's database (of  
all things...) would quite
probably put me off immediately. we are talking about a revision control  
system, not a chat client (or what else).


and I really do believe fossil deserves to gain more following in the  
"DVCS wars" which aim might be harmed by the proposed

approach.

personally, I can trust your statement (that the alphas are "robust"  
(although a contradiction in terms)) and, therefore, do have no problem in  
using fossil this way.

for newcomers the reaction very very probably will be different.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread sky5walk 
Took time to reply, cause I had to clean the coffee I spit up!
A released application should be considered stable and a conservative view
would say its libs should not contain alphas or betas.
The ease of compiling a bleeding edge Fossil.exe is already in place for
those wishing to gain the latest features in trunk.

Fossil is a critical application that deserves its own shelf.

Thanks for Fossil and SQLite!


On Thu, Jan 9, 2014 at 10:21 AM, Remigiusz Modrzejewski
wrote:

>
> On Jan 9, 2014, at 16:14 , Richard Hipp wrote:
>
> > On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski
> > wrote:
> >> I second this view, Fossil is definitely valuable on its own merit.
> >> As such, its stable versions should not contain alpha-quality code from
> >> other projects.
> >>
> >
> > SQLite alphas are more robust that "stables" of most other software
> > projects.
>
> Good point.
> However, this is one that can be hard to explain to distributors.
> It would be a shame to see new Fossil releases not adopted due to that.
> Disclaimer: I have no idea if this would be the case.
> Personally, knowing SQLite testing, I have nothing against using current
> version in my system.
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Ramey, Christopher 
On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp  wrote:

>
> On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski <
> [email protected]> wrote:
>
>>
>> On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:
>>
>> >> But I want Fossil to follow the latest SQLite alphas, not the latest
>> SQLite
>> >> stables.  That's the whole point:  Fossil supports SQLite as a test
>> >> platform.  SQLite stable has already been thoroughly vetted and tested
>> and
>> >> there is little point in testing it further.  I want Fossil to run
>> with the
>> >> latest SQLite on trunk to smoke out bugs early.
>> >
>> > ...but fossil in itself is a pretty awesome piece of software, that's
>> expected
>> > by its users to be stable -- at least for releases.
>>
>> I second this view, Fossil is definitely valuable on its own merit.
>> As such, its stable versions should not contain alpha-quality code from
>> other projects.
>>
>
> SQLite alphas are more robust that "stables" of most other software
> projects.
>

I'd be more concerned about the appearance of using a SQLite alpha in
Fossil. People have to have a great deal of faith in the quality and
stability of their VCS - using anything branded "alpha" even on the
insistence that it's better than most other stables could have a damaging
effect on Fossil's reputation.
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Remigiusz Modrzejewski 

On Jan 9, 2014, at 16:14 , Richard Hipp wrote:

> On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski
> wrote:
>> I second this view, Fossil is definitely valuable on its own merit.
>> As such, its stable versions should not contain alpha-quality code from
>> other projects.
>> 
> 
> SQLite alphas are more robust that "stables" of most other software
> projects.

Good point.
However, this is one that can be hard to explain to distributors.
It would be a shame to see new Fossil releases not adopted due to that.
Disclaimer: I have no idea if this would be the case.
Personally, knowing SQLite testing, I have nothing against using current 
version in my system.

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski
wrote:

>
> On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:
>
> >> But I want Fossil to follow the latest SQLite alphas, not the latest
> SQLite
> >> stables.  That's the whole point:  Fossil supports SQLite as a test
> >> platform.  SQLite stable has already been thoroughly vetted and tested
> and
> >> there is little point in testing it further.  I want Fossil to run with
> the
> >> latest SQLite on trunk to smoke out bugs early.
> >
> > ...but fossil in itself is a pretty awesome piece of software, that's
> expected
> > by its users to be stable -- at least for releases.
>
> I second this view, Fossil is definitely valuable on its own merit.
> As such, its stable versions should not contain alpha-quality code from
> other projects.
>

SQLite alphas are more robust that "stables" of most other software
projects.


-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Lluís Batlle i Rossell 
On Thu, Jan 09, 2014 at 04:12:31PM +0100, Remigiusz Modrzejewski wrote:
> 
> On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:
> 
> >> But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
> >> stables.  That's the whole point:  Fossil supports SQLite as a test
> >> platform.  SQLite stable has already been thoroughly vetted and tested and
> >> there is little point in testing it further.  I want Fossil to run with the
> >> latest SQLite on trunk to smoke out bugs early.
> > 
> > ...but fossil in itself is a pretty awesome piece of software, that's 
> > expected
> > by its users to be stable -- at least for releases.
> 
> I second this view, Fossil is definitely valuable on its own merit.
> As such, its stable versions should not contain alpha-quality code from other 
> projects.

As for me, I think that fossil has showed that it works well enough at almost
any trunk checkin. I understand that the named version sqlite has already been
quite tested; a fossil release with it will only mean *more* tests for sqlite.
It sounds good to me.
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Remigiusz Modrzejewski 

On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:

>> But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
>> stables.  That's the whole point:  Fossil supports SQLite as a test
>> platform.  SQLite stable has already been thoroughly vetted and tested and
>> there is little point in testing it further.  I want Fossil to run with the
>> latest SQLite on trunk to smoke out bugs early.
> 
> ...but fossil in itself is a pretty awesome piece of software, that's expected
> by its users to be stable -- at least for releases.

I second this view, Fossil is definitely valuable on its own merit.
As such, its stable versions should not contain alpha-quality code from other 
projects.

Kind regards,
Remigiusz Modrzejewski



___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Martin S. Weber 
On Thu, Jan 09, 2014 at 09:31:59AM -0500, Richard Hipp wrote:
> On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans  wrote:
> 
> >
> > The latter has the advantage that no new Fossil binary
> > has to be built when SQLite 3.8.3 is released. Fossil will
> > always follow the latest stable SQLite automatically.
> >
> 
> But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
> stables.  That's the whole point:  Fossil supports SQLite as a test
> platform.  SQLite stable has already been thoroughly vetted and tested and
> there is little point in testing it further.  I want Fossil to run with the
> latest SQLite on trunk to smoke out bugs early.

...but fossil in itself is a pretty awesome piece of software, that's expected
by its users to be stable -- at least for releases.

Regards,
-Martin
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans  wrote:

>
> The latter has the advantage that no new Fossil binary
> has to be built when SQLite 3.8.3 is released. Fossil will
> always follow the latest stable SQLite automatically.
>

But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
stables.  That's the whole point:  Fossil supports SQLite as a test
platform.  SQLite stable has already been thoroughly vetted and tested and
there is little point in testing it further.  I want Fossil to run with the
latest SQLite on trunk to smoke out bugs early.
-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Jan Nijtmans 
2014/1/9 Richard Hipp :
> I view Fossil as supporting SQLite, not the other way around.  (Remember,
> that's why Fossil was original written!)  As part of its role of supporting
> SQLite, Fossil serves as a test platform for the latest SQLite alphas.  For
> that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not
> the most recent release.

I already expected that answer, and it's perfectly fine. As developer I
completely agree with that. But package maintainers prefer to
release Fossil with the most stable SQLite, they don't want to
play the role as SQLite testers. As (Cygwin) package maintainer
(for SQLite, not for Fossil) I completely agree with that.

There are two ways package maintainers can get what they
want:
- Replace Fossil's SQLite amagalmation with whatever they
  want, probably SQLite 3.8.2 (maybe with backported bugfixes)
- Compile Fossil with --disable-internal-sqlite.
In both situations, the package maintainers are responsible
for whatever bug this introduces in Fossil.

The latter has the advantage that no new Fossil binary
has to be built when SQLite 3.8.3 is released. Fossil will
always follow the latest stable SQLite automatically.

I hope this is an important argument for keeping
the --disable-internal-sqlite option.

Regards,
   Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Richard Hipp 
On Thu, Jan 9, 2014 at 8:54 AM, Jan Nijtmans  wrote:

> 2014/1/9 Richard Hipp :
> > It has been a few months since the last official release of Fossil.  I
> > wonder if we should consider publishing trunk as the official version
> 1.28?
>
> That's fine with me! I think Fossil's trunk is quite stable now.
>
> One thing to consider would be which SQLite amalgamation should
> be included in it. One way to make both developers and package
> maintainers happy (as being discussed in Fossil-Users
> mailing list) could be:
>
> 1) Create a "branch-1.28" from fossil trunk now (or any
>other suitable moment in the future).
> 2) Create a SQLite amalgamation from here:
>
>and replace Fossil's sqlite3.c and sqlite3.h
>in Fossil's "branch-1.28" branch.
>

I view Fossil as supporting SQLite, not the other way around.  (Remember,
that's why Fossil was original written!)  As part of its role of supporting
SQLite, Fossil serves as a test platform for the latest SQLite alphas.  For
that reason, I want Fossil 1.28 to have the very latest trunk of SQLite,
not the most recent release.



>
> Then trunk can be continued to be developed with
> the latest-and-greatest SQLite version, while
> Fossil 1.28 will be release with the
> best-tested-and-most-stable SQLite version.
>
> Of course, more bug-fixes could be merged to
> SQLite's "branch-3.8.2" branch, but I don't see
> any which are relevant to Fossil.
>
> Regards,
> Jan Nijtmans
> ___
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
[email protected]
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

2014-01-09 Thread Jan Nijtmans 
2014/1/9 Richard Hipp :
> It has been a few months since the last official release of Fossil.  I
> wonder if we should consider publishing trunk as the official version 1.28?

That's fine with me! I think Fossil's trunk is quite stable now.

One thing to consider would be which SQLite amalgamation should
be included in it. One way to make both developers and package
maintainers happy (as being discussed in Fossil-Users
mailing list) could be:

1) Create a "branch-1.28" from fossil trunk now (or any
   other suitable moment in the future).
2) Create a SQLite amalgamation from here:
   
   and replace Fossil's sqlite3.c and sqlite3.h
   in Fossil's "branch-1.28" branch.

Then trunk can be continued to be developed with
the latest-and-greatest SQLite version, while
Fossil 1.28 will be release with the
best-tested-and-most-stable SQLite version.

Of course, more bug-fixes could be merged to
SQLite's "branch-3.8.2" branch, but I don't see
any which are relevant to Fossil.

Regards,
Jan Nijtmans
___
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users