[EMAIL PROTECTED] wrote:
One thing: the patch server will have to run over HTTPS - that way we
can know that it is who it says it is.
Right, I'm not sure if the computer I'm proofing it on is the best
place for it so I didn't bother with the HTTPS, but should be trivial
to have it.
Yes, t
On 1/17/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 1/12/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > What do you think about setting up the buildfarm clients
>> > with the users they are willing to test patches for, as opposed to
[EMAIL PROTECTED] wrote:
On 1/12/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> What do you think about setting up the buildfarm clients
> with the users they are willing to test patches for, as opposed to
> having the patch system track who is are trusted users? My th
On 1/12/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> What do you think about setting up the buildfarm clients
> with the users they are willing to test patches for, as opposed to
> having the patch system track who is are trusted users? My thoughts
> are the former is
[EMAIL PROTECTED] wrote:
What do you think about setting up the buildfarm clients
with the users they are willing to test patches for, as opposed to
having the patch system track who is are trusted users? My thoughts
are the former is easier to implement and that it allows anyone to use
the buil
On 1/11/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
>>
>> I am not clear about what is being proposed. Currently buildfarm syncs
>> against (or pulls a fresh copy from, depending on configuration) either
>> the main anoncvs repo or a mirror (which you can get using cvsu
[EMAIL PROTECTED] wrote:
I am not clear about what is being proposed. Currently buildfarm syncs
against (or pulls a fresh copy from, depending on configuration) either
the main anoncvs repo or a mirror (which you can get using cvsup or
rsync,
among other mechanisms). I can imagine a mechanism
On 1/4/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Gavin Sherry wrote:
> On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
>
>> 1. Pull source directly from repositories (cvs, git, etc.) PLM
>> doesn't really track actually scm repositories. It requires
>> directories of source code to be traversed
On Jan 11, 2007, at 10:35 , Richard Troy wrote:
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
Wouldn't there be some value to knowing whether the patch failed
due to
bitrot vs it just didn't work on some platforms out of the gat
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
>
> On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
> > >Wouldn't there be some value to knowing whether the patch failed
> > >due to
> > >bitrot vs it just didn't work on some platforms out of the gate?
> >
> > I'm having a hard time fi
On Wed, 10 Jan 2007, Jim C. Nasby wrote:
> On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
> > >Wouldn't there be some value to knowing whether the patch failed
> > >due to
> > >bitrot vs it just didn't work on some platforms out of the gate?
> >
> > I'm having a hard time figu
On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
> >Wouldn't there be some value to knowing whether the patch failed
> >due to
> >bitrot vs it just didn't work on some platforms out of the gate?
>
> I'm having a hard time figuring out what that value would be. How
> would th
On Jan 9, 2007, at 20:41 , Jim C. Nasby wrote:
On Mon, Jan 08, 2007 at 10:40:16PM -0600, Michael Glaesemann wrote:
On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
Actually, I see point in both... I'd think you'd want to know if a
patch
worked against the CVS checkout it was written against.
On Mon, Jan 08, 2007 at 10:40:16PM -0600, Michael Glaesemann wrote:
>
> On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
>
> >Actually, I see point in both... I'd think you'd want to know if a
> >patch
> >worked against the CVS checkout it was written against.
>
> Regardless, it's unlikely that
On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
Actually, I see point in both... I'd think you'd want to know if a
patch
worked against the CVS checkout it was written against.
Regardless, it's unlikely that the patch was tested against all of
the platforms available on the build farm. If
On Fri, Jan 05, 2007 at 11:02:32PM -0600, Andrew Dunstan wrote:
> Tom Lane wrote:
> > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >> Jim Nasby wrote:
> >>> More important, I see no reason to tie applying patches to pulling
> >>> from CVS. In fact, I think it's a bad idea: you want to build just
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Jim Nasby wrote:
>>> More important, I see no reason to tie applying patches to pulling
>>> from CVS. In fact, I think it's a bad idea: you want to build just
>>> what's in CVS first, to make sure that it's working, before you start
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Jim Nasby wrote:
>> More important, I see no reason to tie applying patches to pulling
>> from CVS. In fact, I think it's a bad idea: you want to build just
>> what's in CVS first, to make sure that it's working, before you start
>> testing any patches
Jim Nasby wrote:
> On Jan 5, 2007, at 10:24 AM, Andrew Dunstan wrote:
>> cvs update isn't too bad either. I just did a substantial update on
>> a tree that had not been touched for nearly 6 months, and ethereal
>> tells me that total traffic was 7343004 bytes in 7188 packets.
>> Individual buildf
On Jan 5, 2007, at 10:24 AM, Andrew Dunstan wrote:
cvs update isn't too bad either. I just did a substantial update on
a tree that had not been touched for nearly 6 months, and ethereal
tells me that total traffic was 7343004 bytes in 7188 packets.
Individual buildfarm updates are going to b
Tino Wildenhain wrote:
[EMAIL PROTECTED] schrieb:
On 1/4/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
...
Pulling branches from
anonvcvs regularly might be burdensome bandwidth-wise. So, like you
say, a
local mirror would be beneficial for patch test
Andrew Dunstan wrote:
Gavin Sherry wrote:
With PLM, you could test patches against various code branches. I'd
guessed Mark would want to provide this capability. Pulling branches from
anonvcvs regularly might be burdensome bandwidth-wise. So, like you say, a
local mirror would be beneficial for
[EMAIL PROTECTED] schrieb:
On 1/4/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
...
Pulling branches from
anonvcvs regularly might be burdensome bandwidth-wise. So, like you
say, a
local mirror would be beneficial for patch testing.
Right some sort o
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> >
> > With PLM, you could test patches against various code branches. I'd
> > guessed Mark would want to provide this capability. Pulling branches from
> > anonvcvs regularly might be burdensome bandwidth-wise. So, like you say, a
>
Gavin Sherry wrote:
>
> With PLM, you could test patches against various code branches. I'd
> guessed Mark would want to provide this capability. Pulling branches from
> anonvcvs regularly might be burdensome bandwidth-wise. So, like you say, a
> local mirror would be beneficial for patch testing.
On 1/4/07, Gavin Sherry <[EMAIL PROTECTED]> wrote:
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> >> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> >> doesn't really track actually scm repositories. It req
On Thu, 4 Jan 2007, Andrew Dunstan wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> >> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> >> doesn't really track actually scm repositories. It requires
> >> directories of source code to be traversed
Gavin Sherry wrote:
> On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
>
>> 1. Pull source directly from repositories (cvs, git, etc.) PLM
>> doesn't really track actually scm repositories. It requires
>> directories of source code to be traversed, which are set up by
>> creating mirrors.
>
> It seems
On Thu, 4 Jan 2007, Alvaro Herrera wrote:
> Gavin Sherry wrote:
> > On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> >
> > > 1. Pull source directly from repositories (cvs, git, etc.) PLM
> > > doesn't really track actually scm repositories. It requires
> > > directories of source code to be traver
Gavin Sherry wrote:
> On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
>
> > 1. Pull source directly from repositories (cvs, git, etc.) PLM
> > doesn't really track actually scm repositories. It requires
> > directories of source code to be traversed, which are set up by
> > creating mirrors.
>
> It
On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
> 1. Pull source directly from repositories (cvs, git, etc.) PLM
> doesn't really track actually scm repositories. It requires
> directories of source code to be traversed, which are set up by
> creating mirrors.
It seems to me that a better approach
OSDL had a tool called PLM with a primary goal to test patches against
the Linux kernel. It applied them and built them on multiple
platforms. It's a pretty simple idea and here are some links to what
it did; the systems appear to still be up for the moment so here are a
couple of links to what
32 matches
Mail list logo
