A dearth of release managers, for example. Among the other things that
dearth is a bigger problem than is the absence of nightly builds. :)
This is also the reason that 1.4.x has stagnated - it's been 16 months since
1.4.14.1, and getting on for two years since 1.4.14. Andrew has been doing
If a pre-stable - master merge to trunk happens reliably every 3
months, it might be an obnoxious merge, but it can't be any worse
than merging rxk5 (for gory details, see
https://bitbucket.org/dahozer/tfs/changeset/10a38e703483fd99b3a41e99cba74f203524f731
)
The artificial version approach you
On Mon, Sep 17, 2012 at 08:06:39PM +0100, Simon Wilkinson wrote:
On 17 Sep 2012, at 19:54, Troy Benjegerdes wrote:
If 'rebuild with debug' symbols is the answer to find the segfault, then why
don't we change './regen ./configure make check' to turn on debug
symbols
by default (at
On Tue, Sep 18, 2012 at 10:31 AM, Troy Benjegerdes ho...@hozed.org wrote:
On Mon, Sep 17, 2012 at 08:06:39PM +0100, Simon Wilkinson wrote:
On 17 Sep 2012, at 19:54, Troy Benjegerdes wrote:
If 'rebuild with debug' symbols is the answer to find the segfault, then
why
don't we change
On Tue, Sep 18, 2012 at 10:39:45AM -0400, Derrick Brashear wrote:
On Tue, Sep 18, 2012 at 10:31 AM, Troy Benjegerdes ho...@hozed.org wrote:
On Mon, Sep 17, 2012 at 08:06:39PM +0100, Simon Wilkinson wrote:
On 17 Sep 2012, at 19:54, Troy Benjegerdes wrote:
If 'rebuild with debug' symbols
On Tue, Sep 18, 2012 at 10:47 AM, Troy Benjegerdes ho...@hozed.org wrote:
On Tue, Sep 18, 2012 at 10:39:45AM -0400, Derrick Brashear wrote:
On Tue, Sep 18, 2012 at 10:31 AM, Troy Benjegerdes ho...@hozed.org wrote:
On Mon, Sep 17, 2012 at 08:06:39PM +0100, Simon Wilkinson wrote:
On 17 Sep
On Tue, 18 Sep 2012 10:39:45 -0400
Derrick Brashear sha...@gmail.com wrote:
What documentation on libtool/autoconf/etc/whatever should I be looking at
to make '--enable-checking' and '--enable-debug' be the default when I do
'./regen ./configure make check' so I can submit a patch for
[snip]
None of those steps knows about another, nor should they. If you want
to enable debugging, just do it.
If you want to provide a script which does debug builds, do it.
Anything else is pointless complexity.
Debug symbols are pointless complexity ;)
If they are something you
On Tue, Sep 18, 2012 at 12:54 PM, Troy Benjegerdes ho...@hozed.org wrote:
[snip]
If there's a perceived performance impact to having debug on in a release
build, then I want to see a full QA test and benchmark results showing that
it's actually slowing things down.
Well, as soon as you
On Tue, Sep 18, 2012 at 01:12:33PM -0400, Derrick Brashear wrote:
On Tue, Sep 18, 2012 at 12:54 PM, Troy Benjegerdes ho...@hozed.org wrote:
[snip]
If there's a perceived performance impact to having debug on in a release
build, then I want to see a full QA test and benchmark results
That's not a big deal. What's a big deal is I'll spend about 10 or 15 more
hours arguing on the mailing list or on gerrit for a very simple change to
make sure the default builds ensure I can always send you a reasonable
stack trace.
You clearly have a script you're using to make these
Troy,
I like where this is going. Here are the immediate hurdles. I am
indeed just another ISP customer behind NAT layers. I've been
interested in setting up dynamic DNS, but have not yet done it. My
travel schedule for the week changed today, which will prevent me from
working on the debian
Thanks everyone who replied. There was a lot of email on this thread,
so I'm going to write a quick summary.
There are concerns that this would increase the support load on
organizational helpdesks that support AFS internally, and on the
OpenAFS community overall.
There are concerns that
How about an effort to get nightly builds of master available on as many
platforms as possible, and getting thousands of bored college students to
download, install, and test them?
I think that's still overly optimistic. There's a lot of moving parts here; you
just can't just install a
I'm looking to get all the low-hanging fruit with unskilled testing.
Particularly with regressions like this:
hozer@six:~/src/openafs-fuse-git/tests/fuse$
/home/hozer/src/openafs-fuse-git/tests/fuse/../../src/afsd/afsd.fuse -dynroot
-fakestat -d -confdir
On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes ho...@hozed.org wrote:
I'm looking to get all the low-hanging fruit with unskilled testing.
Particularly with regressions like this:
hozer@six:~/src/openafs-fuse-git/tests/fuse$
Troy Benjegerdes ho...@hozed.org writes:
I'm looking to get all the low-hanging fruit with unskilled testing.
Particularly with regressions like this:
hozer@six:~/src/openafs-fuse-git/tests/fuse$
/home/hozer/src/openafs-fuse-git/tests/fuse/../../src/afsd/afsd.fuse -dynroot
-fakestat -d
On Mon, Sep 17, 2012 at 2:28 PM, Russ Allbery r...@stanford.edu wrote:
Troy Benjegerdes ho...@hozed.org writes:
I'm looking to get all the low-hanging fruit with unskilled testing.
Particularly with regressions like this:
hozer@six:~/src/openafs-fuse-git/tests/fuse$
Hi,
Well, we used the fuse rather extensively for locking and dirformat testing.
It's experimental, but science experiment might be a little strong.
Matt
- Russ Allbery r...@stanford.edu wrote:
Troy Benjegerdes ho...@hozed.org writes:
I'm looking to get all the low-hanging fruit
FUSE library version: 2.8.6
nullpath_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.17
flags=0x047b
max_readahead=0x0002
Starting AFS cache scan...found 0 non-empty cache files (0%).
afsd: All AFS daemons started.
Segmentation fault
The fuse code
On Mon, Sep 17, 2012 at 2:54 PM, Troy Benjegerdes ho...@hozed.org wrote:
FUSE library version: 2.8.6
nullpath_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.17
flags=0x047b
max_readahead=0x0002
Starting AFS cache scan...found 0 non-empty cache files (0%).
On 17 Sep 2012, at 19:54, Troy Benjegerdes wrote:
If 'rebuild with debug' symbols is the answer to find the segfault, then why
don't we change './regen ./configure make check' to turn on debug
symbols
by default (at least in master.. we can turn it back off in a release)
If you are
On 17 Sep 2012, at 17:25, David Boyes wrote:
'make check' on a single machine will never give you useful testing results
other than to find packaging or smoke test errors, which aren't all that
helpful overall.
I agree with you with regards to crowd sourced testing, but I just wanted to
Derrick Brashear sha...@gmail.com writes:
On Mon, Sep 17, 2012 at 2:28 PM, Russ Allbery r...@stanford.edu wrote:
The fuse code currently in the tree was primarily a science experiment
by one developer and is not something that's really ready for
production use. That's not to say this isn't a
Matt W. Benjamin m...@linuxbox.com writes:
Well, we used the fuse rather extensively for locking and dirformat
testing. It's experimental, but science experiment might be a little
strong.
Ah, okay, it's gotten more attention than I thought.
--
Russ Allbery (r...@stanford.edu)
-Original Message-
From: Simon Wilkinson [mailto:s...@your-file-system.com]
On 17 Sep 2012, at 17:25, David Boyes wrote:
'make check' on a single machine will never give you useful testing
results other than to find packaging or smoke test errors, which aren't all
that helpful
On 17 Sep 2012, at 23:18, Andrew Deason wrote:
I don't think you can make that say something based on 1.6.1, since the
head of the 1.6.x branch right now is a different branch than 1.6.1. I
mean, if git-version said something like this is 1.6.1 plus N patches,
that would be incorrect.
Simon Wilkinson s...@your-file-system.com writes:
We're not consistent about whether we release from trunk, or release
from a branch. This means that on some occasions the trunk has the tag,
and on others the branch. In a traditional git world, we would have
branched for 1.6.1, committed the
So. Were you perchance using it on a Mac? Probably a 64 bit Intel mac?
http://gerrit.openafs.org/#change,8132
As nearly as I can tell, this is a very specific problem. The code is fine. The
circumstances of building afsd.fuse meant it was collateral damage when we
started using roken, but only
Nope, Debian x86-64
Any chance the buildbots can be easily modified to run make check/make tests?
I'm really curious what debian ppc32/ppc64 will do. I have an arm build, but
no fuse kernel module (debian on an sdcard on an android tablet).
On Mon, Sep 17, 2012 at 11:39:55PM -0400, Derrick
the tests are not ready to be run on the buildslaves. it's been
working toward that point, but not yet.
On Tue, Sep 18, 2012 at 12:08 AM, Troy Benjegerdes ho...@hozed.org wrote:
Nope, Debian x86-64
Any chance the buildbots can be easily modified to run make check/make tests?
I'm really
Troy,
I'm unclear I've offered you anything you can actually use. Mostly,
I'm offering you the reality check of a non-programmer, a Macbook with
me on the road and a stale Debian box powered down back at home.
You'll have to steer me through downloading, installing and using
anything that's not
Here's my thought:
Spend your 5 start-up hours either re-installing or upgrading your Debian
system to squeeze (the current debian stable). Try doing 'apt-get install
openafs-fileserver', and then, if it works, please edit
https://bitbucket.org/dahozer/tfs/wiki/Home saying so, or if it does not,
On 9/15/2012 12:18 AM, Troy Benjegerdes wrote:
verbiage snipped
Here's some code.
http://gerrit.openafs.org/#change,6844
The test itself is probably fine but the custom licensing is not.
OpenAFS accepts IPL1.0, MIT, and Simple BSD. Pick one.
Quick question: How many of these 1130
On Fri, Sep 14, 2012 at 04:06:12PM -0500, David Boyes wrote:
Just to say explicitly, while OpenAFS developers are certainly welcome to
use whatever techniques make sense to them, I am completely uninterested
in doing anything at all with any of those half-assed meta-build systems and
will
Sometimes I think we get hung up on 'good testing' vs having *something*.
The last time I worked for someone else, it was writing test code for Cray's
supercomputer systems. You don't get much more complex than a machine
with 30,000 cores in which 'acceptable' performance is defined as 'pushing
Troy,
If you set this up, I'm willing to be your guinea pig. It'll cost you
enough support and/or documentation to get me over initial learning
curve.
Doug
On 9/15/12, Troy Benjegerdes ho...@hozed.org wrote:
Sometimes I think we get hung up on 'good testing' vs having *something*.
The last
I'll buy that for a few emails.
Let's start by having you take a look at:
https://bitbucket.org/dahozer/tfs
There are tabs for issues wikis, so sign up for a bitbucket account and
ask some questions there, so we don't spam the -devel list with lots of
'how do I xyz' questions
For the
My big concern is that nightly installable builds will be a support
nightmare.
There are a large number of users that will always take the latest
no matter what.
I know. Been in support. However, when X does not work it helps a
lot if some $USER - even if he can't spell g i t or . / c o n f
Don't think of this as a nightmare, think of this as an opportunity for
support contract upsales.
nightly installable builds and enthusiastic users that install the latest
one every day will make for a much more reliable product, and catch
problems before they show up and cause trouble for
However, this requires having a much greater availability of release
management and testing resources.
And perhaps an argument for automated tests that could prove out a release?
If you mean manual testing resources, given the scope of platform support and
myriad branches for OpenAFS I
On Thu, 13 Sep 2012, Chaz Chandler wrote:
no objection here, esp. if there's anyone out there with the spare time
for and interest in testing them.
Most distro/OSes have their own packaging system, and it would seem that
life would be easier for such potential testers if they could install a
On Fri, Sep 14, 2012 at 9:04 AM, Benjamin Kaduk ka...@mit.edu wrote:
On Thu, 13 Sep 2012, Chaz Chandler wrote:
Also, there is a question of what version number to put on snapshots so that
they will sort properly between real releases.
Ordinarily git describe would be an easy way to come up
On Fri, Sep 14, 2012 at 9:12 AM, Troy Benjegerdes ho...@hozed.org wrote:
However, this requires having a much greater availability of release
management and testing resources.
And perhaps an argument for automated tests that could prove out a release?
If you mean manual testing resources,
On Fri, 14 Sep 2012, Ken Dreyer wrote:
On Fri, Sep 14, 2012 at 9:04 AM, Benjamin Kaduk ka...@mit.edu wrote:
On Thu, 13 Sep 2012, Chaz Chandler wrote:
Also, there is a question of what version number to put on snapshots so that
they will sort properly between real releases.
Ordinarily git
Most distro/OSes have their own packaging system, and it would seem that
life would be easier for such potential testers if they could install a
snapshot
of openafs within their packaging system.
I would argue that there's no value at all in doing this if this isn't the
case. Installing
All this talk about 'reliable code for our users' is total BS until
'make check' actually does some realisitic functionality tests.
If you can't write an automated test for a feature, they I would
request we consider disabling that feature.
I'm not sure this is a realistic goal in a
On Fri, 14 Sep 2012 08:12:42 -0500
Troy Benjegerdes ho...@hozed.org wrote:
However, this requires having a much greater availability of release
management and testing resources.
And perhaps an argument for automated tests that could prove out a release?
If you mean manual testing
David Boyes dbo...@sinenomine.net writes:
There have been several discussions in the past on using a meta-build
system like cmake or similar to try to address this, or at least using
the packaging components. Some reorganization of the build process would
probably be desirable to really take
Just to say explicitly, while OpenAFS developers are certainly welcome to
use whatever techniques make sense to them, I am completely uninterested
in doing anything at all with any of those half-assed meta-build systems and
will not assist in using them on Debian. I believe they're
On 9/14/2012 12:12 PM, David Boyes wrote:
All this talk about 'reliable code for our users' is total BS until
'make check' actually does some realisitic functionality tests.
If you can't write an automated test for a feature, they I would
request we consider disabling that feature.
I'm not
Troy Benjegerdes ho...@hozed.org writes:
All this talk about 'reliable code for our users' is total BS until
'make check' actually does some realisitic functionality tests.
Speaking as someone who has worked on adding a test framework to OpenAFS
and who is obsessive about test-driven
In this case I think you are low-balling the estimate. To do it right it
isn't
sufficient to test one build against itself. You need to test new clients
against a range of old servers and vice versa in a constrained environment.
It is necessary to be able to identify when a change has an
On 9/14/2012 9:12 AM, Troy Benjegerdes wrote:
However, this requires having a much greater availability of release
management and testing resources.
And perhaps an argument for automated tests that could prove out a release?
If you mean manual testing resources, given the scope of platform
verbiage snipped
Here's some code.
http://gerrit.openafs.org/#change,6844
As Tom Keiser wrote to you a few days ago. Start contributing code
that is useable to OpenAFS today. If you want to write tests, people
will jump up and down with joy. However, please do not stomp your feet
and
Would it be feasible or desirable to have Buildbot actually provide
install-able packages (eg. RPMs on Linux, MSIs on Windows)? It could
help new users confirm yes, this change fixes my bug.
- Ken
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
we talked about doing it for releases; this would be a generalized case of it
possibly, but i can see it becoming a support nightmare. you're running what??
On Thu, Sep 13, 2012 at 12:21 PM, Ken Dreyer ktdre...@ktdreyer.com wrote:
Would it be feasible or desirable to have Buildbot actually
At least on Windows, 'no'. The builders have no access to
certificates and private keys necessary for digital signatures and do
not build either the documentation nor the installation packages.
Building complete installation packages would increase the build time
by more than a factor of
Are there any objections to doing this for non-windows platforms? It
could be a nightly build.
On 09/13/2012 12:35 PM, Derrick Brashear wrote:
we talked about doing it for releases; this would be a generalized case of it
possibly, but i can see it becoming a support nightmare. you're running
My big concern is that nightly installable builds will be a support
nightmare.
There are a large number of users that will always take the latest no
matter what.
I realize there is an argument to be made for users being free to do
hang themselves. But I question whether that is what
no objection here, esp. if there's anyone out there with the spare time for and
interest in testing them.
-Original Message-
From: ja...@rampaginggeek.com
Sent: Thu, 13 Sep 2012 20:21:08 -0400
To: sha...@gmail.com
Subject: Re: [OpenAFS] buildbot and packages
Are there any
...@rampaginggeek.com
Sent: Thu, 13 Sep 2012 20:21:08 -0400
To: sha...@gmail.com
Subject: Re: [OpenAFS] buildbot and packages
Are there any objections to doing this for non-windows platforms? It
could be a nightly build.
On 09/13/2012 12:35 PM, Derrick Brashear wrote:
we talked about doing
62 matches
Mail list logo
