On 2009-Oct-14 15:43:33 +0100, "Dr. David Kirkby"
wrote:
>The best I have seen in open-source development for this sort of thing
>is the wireshark developers list. Join that for a week and see what
>messages you get.
FreeBSD also has automated build bots for both the core OS (currently
4 suppo
On Wed, Oct 14, 2009 at 10:49:18AM +0200, Burcin Erocal wrote:
> > I wonder if the "lieutenant" model used by Linux kernel development
> > might be helpful here? If there was one or two people (lieutenants)
> > responsible for each broad area of Sage, and trusted to merge patches,
Somehow, that'
On Oct 16, 1:14 am, Minh Nguyen wrote:
> Hi David,
>
> On Fri, Oct 16, 2009 at 11:04 AM, Dr. David Kirkby
>
> wrote:
>
>
>
> > if you want access to a HP-UX machine, I can create you an account.
>
> Sure. Thank you for the offer. My preferred username is "mvngu".
I've sent you details by pri
Hi David,
On Fri, Oct 16, 2009 at 11:04 AM, Dr. David Kirkby
wrote:
> if you want access to a HP-UX machine, I can create you an account.
Sure. Thank you for the offer. My preferred username is "mvngu".
> I can't guarantee I will run the thing 24/7 forever, as it uses quite a
> bit of powe
Minh Nguyen wrote:
> Like you, I also compile and doctest Sage on the following machines:
>
> * High-end servers
> * bsd.math --- Mac OS X 10.6.1
> * rosemary.math (outside the Sage network of computers) --- 64-bit
> Red Hat Enterprise Linux Server 5.4
> * sage.math --- 64-bit Ubuntu 8.04.
Robert Bradshaw wrote:
> For someone
> who has a hobby of building complex software on a wide variety of
> systems (and I'm very glad people like you are out there as the Sage
> project wouldn't be where it is without it) doing this is no burden at
> all. I'd rather spend my time thinking
On Oct 14, 2009, at 7:09 AM, kcrisman wrote:
>>> I don't think this would work at all, unless there is an *easy*
>>> automated procedure to submit a patch to a bot which (a) applies the
>>> patch to the current tree (b) compiles in all platforms (c) attaches
>>> the logs to the ticket and possibl
On Oct 14, 2009, at 5:27 AM, Gonzalo Tornaria wrote:
> On Wed, Oct 14, 2009 at 6:49 AM, Burcin Erocal
> wrote:
>> The status of "lieutenant" is the equivalent of having "commit
>> access"
>> in other open source projects. I would prefer a different term for
>> "lieutenant", but I don't have
On Wed, Oct 14, 2009 at 10:07 AM, Jason Grout
wrote:
>
> William Stein wrote:
>
>> I hope soon we'll have a web-based interface that allows one to easily
>> change Sage code using Bespin (that code editor), make patches, test
>> changes (on 10 platforms), etc., all trivially from a web browser vi
William Stein wrote:
> I hope soon we'll have a web-based interface that allows one to easily
> change Sage code using Bespin (that code editor), make patches, test
> changes (on 10 platforms), etc., all trivially from a web browser via
> a webapp.
What do you mean by "hope soon":
1. People ar
On Wed, Oct 14, 2009 at 2:12 AM, Dr. David Kirkby
wrote:
> 2) When submitting a patch, they attach logs showing building on all
> platforms, *except* the one they normally work on, since one can assume
> they have probably got their patch working there.
>
> This really is no more than an extensio
On Oct 14, 11:22 am, Minh Nguyen wrote:
> Hi kcrisman,
>
> On Thu, Oct 15, 2009 at 2:16 AM, kcrisman wrote:
>
>
>
> > Nope, I think we start with Tiger (10.4). In fact, definitely won't
> > work with the fix for dynamic links or whatever we did for cliquer.
> > I'm hoping to hang on to this
Hi kcrisman,
On Thu, Oct 15, 2009 at 2:16 AM, kcrisman wrote:
> Nope, I think we start with Tiger (10.4). In fact, definitely won't
> work with the fix for dynamic links or whatever we did for cliquer.
> I'm hoping to hang on to this one for a little longer for the same
> purpose, but we'll
Hi David,
On Thu, Oct 15, 2009 at 1:43 AM, Dr. David Kirkby
wrote:
> Setting up such a build-bot is not something I have ever attempted. I
> would imagine is quite a bit of work to get it right.
Indeed it does when one considers that a build-bot would need to
initiate a build of an alpha, rc
On Oct 14, 10:45 am, Jason Grout wrote:
> kcrisman wrote:
>
> >>> I don't think this would work at all, unless there is an *easy*
> >>> automated procedure to submit a patch to a bot which (a) applies the
> >>> patch to the current tree (b) compiles in all platforms (c) attaches
> >>> the logs
kcrisman wrote:
>
>
>>> I don't think this would work at all, unless there is an *easy*
>>> automated procedure to submit a patch to a bot which (a) applies the
>>> patch to the current tree (b) compiles in all platforms (c) attaches
>>> the logs to the ticket and possibly flags the ticket depen
kcrisman wrote:
>
> Fascinating discussion.
>
> I just want to emphasize two things as a representative of those who
> knew virtually nothing about programming or open source when we
> started.
>
> 1) If you're serious about this doctesting (esp. on different
> platforms) thing, there has to be
> > I don't think this would work at all, unless there is an *easy*
> > automated procedure to submit a patch to a bot which (a) applies the
> > patch to the current tree (b) compiles in all platforms (c) attaches
> > the logs to the ticket and possibly flags the ticket depending on the
> > resu
Gonzalo Tornaria wrote:
> On Wed, Oct 14, 2009 at 7:12 AM, Dr. David Kirkby
> wrote:
>> 2) When submitting a patch, they attach logs showing building on all
>> platforms, *except* the one they normally work on, since one can assume
>> they have probably got their patch working there.
>
> I don't
Fascinating discussion.
I just want to emphasize two things as a representative of those who
knew virtually nothing about programming or open source when we
started.
1) If you're serious about this doctesting (esp. on different
platforms) thing, there has to be a way to make it drop-dead easy -
On Wed, Oct 14, 2009 at 7:12 AM, Dr. David Kirkby
wrote:
> 2) When submitting a patch, they attach logs showing building on all
> platforms, *except* the one they normally work on, since one can assume
> they have probably got their patch working there.
I don't think this would work at all, unle
On Wed, Oct 14, 2009 at 6:49 AM, Burcin Erocal wrote:
> The status of "lieutenant" is the equivalent of having "commit access"
> in other open source projects. I would prefer a different term for
> "lieutenant", but I don't have anything better now.
What about "editor"?
Gonzalo
--~--~-
On Oct 14, 1:30 pm, gsw wrote:
> How about intertwining these two phases?
i don't know how manageable this is, especially when patches depend on
each other and so on.
a similar approach would be to have a main trunk, like an inifite
alpha, and from time to time a second release manager picks
Hi,
there's another possibility to speed up the Sage release frequency, by
a certain parallelization.
Currently, the Sage releases are done sequentially, and in two phases:
- the "alpha" phase, where tons of tickets are merged, and new
functionality gets in
- the "release cadidate" phase, where
On Oct 14, 7:28 am, Rob Beezer wrote:
> I wonder if the "lieutenant" model used by Linux kernel development
> might be helpful here?
Ok, I've read this and to make sure you all are not talking about
different things: there are two ways to split the workload:
- horizontally: Sage itself is spl
Hi!
Part of the problem seems money. IIRC there is some funding by Google
and by Sun. Can this be used to pay release management?
On Oct 14, 6:28 am, Rob Beezer wrote:
> [...]
> I wonder if the "lieutenant" model used by Linux kernel development
> might be helpful here? If there was one or two
William Stein wrote:
> I think a huge amount of the problem will be that many of those 66
> positive reviewed tickets probably will:
> (2) many of the patches will probably fail on 32-bit or ppc or OS X,
> even though they worked fine on sage.math.
In a post yesterday I said:
---
Hi,
On Tue, 13 Oct 2009 23:21:37 -0700
William Stein wrote:
> What is "release management"?Right now there are *66* tickets
> listed as "positive review" right here:
>http://trac.sagemath.org/sage_trac/report/11
>
> Definition: Release management is the process of taking th
Hello,
On Wed, Oct 14, 2009 at 1:21 PM, William Stein wrote:
> Definition: Release management is the process of taking these tickets,
> applying them, bouncing those that don't work, creating a sage-4.2.tar
> that works on our supported platforms, and creating binaries. If an
> unacceptable nu
On Tue, Oct 13, 2009 at 10:43 PM, Craig Citro wrote:
>
>>> And, let's be honest, no
>>> release cycle is really going to be much shorter than that.
>>
>> Are you sure? I personally did 100% of the releases for 3 years with
>> an average of 1-week for the release cycle.
>>
>
> Who knows -- maybe
On Oct 13, 2009, at 10:43 PM, Craig Citro wrote:
>
>>> And, let's be honest, no
>>> release cycle is really going to be much shorter than that.
>>
>> Are you sure? I personally did 100% of the releases for 3 years
>> with
>> an average of 1-week for the release cycle.
>>
>
> Who knows -- mayb
>> And, let's be honest, no
>> release cycle is really going to be much shorter than that.
>
> Are you sure? I personally did 100% of the releases for 3 years with
> an average of 1-week for the release cycle.
>
Who knows -- maybe I'm wrong? Do you want to test it? Try doing
sage-4.2 in a week.
It's been discussed before, but maybe it is relevant for this
discussion. Realize I have zero experience with release management
and an incomplete understanding of everything involved, so take this
for what it is worth.
I wonder if the "lieutenant" model used by Linux kernel development
might be
On Oct 13, 2009, at 9:30 PM, William Stein wrote:
> On Tue, Oct 13, 2009 at 9:14 PM, Robert Bradshaw
> wrote:
>> I was just about to compose a long email on this thread, but you've
>> essentially hit every point I wanted to make. In fact, I see no
>> advantage for long release cycles at all--it'
On Tue, Oct 13, 2009 at 9:33 PM, Craig Citro wrote:
>
>> The question is what, exactly, makes actually
>> getting releases out so difficult? Is most of the time spent getting
>> things working on uncommon (presumably little-tested) systems? Are the
>> obstructions typically due to patches that we
> The question is what, exactly, makes actually
> getting releases out so difficult? Is most of the time spent getting
> things working on uncommon (presumably little-tested) systems? Are the
> obstructions typically due to patches that were not actually ready to
> go in (despite positive reviews)
On Tue, Oct 13, 2009 at 9:14 PM, Robert Bradshaw
wrote:
> I was just about to compose a long email on this thread, but you've
> essentially hit every point I wanted to make. In fact, I see no
> advantage for long release cycles at all--it's more work for the
> release manager, and it's not like u
On Oct 13, 2009, at 8:09 PM, Jason Grout wrote:
> Dr. David Kirkby wrote:
>
>>
>> I know we have had this discussion before, but I do not seem to be
>> alone
>> on my views on this one.
>>
>> It is not clear to me there needs to be very frequent releases. I
>> know
>> you say Apple itunes bri
I mostly agree. 2 months is acceptable. 6 months seems too long for
all the reaons Jason articulated.
-Marshall
On Oct 13, 10:09 pm, Jason Grout wrote:
> As it is, there is a semi-major research code contribution I plan to
> make before Christmas that will be needed at a workshop in January,
Dr. David Kirkby wrote:
>
> I know we have had this discussion before, but I do not seem to be alone
> on my views on this one.
>
> It is not clear to me there needs to be very frequent releases. I know
> you say Apple itunes brings out a new release every couple of weeks, but
> this is quit
William Stein wrote:
> On Tue, Oct 13, 2009 at 7:09 PM, William Stein wrote:
>> Wow, it has been a full 2 months since a Sage release.
>> How do I find source code for old releases of SAGE!?
>
> The reason I was looking is because it has been exactly 2 months since
> the last Sage release, to t
41 matches
Mail list logo
