On 2/26/07, Josh Berkus wrote:
Andrew,
> Is there a list of projects? Or can we suggest some?
Suggest away, please!
I'm going to update the website soon, would appreciate new content.
I can also volunteer to mentor continuing work on a TPC-E kit, for C
stored procedures and improved results
On 2/26/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Josh Berkus wrote:
> The next Summer of Code is just around the corner.
>
> Last year, we had 46 submissions and seven we accepted. Out of the SoC we got
> two ongoing contributors, several good patches, two code refactors and even
> an emplo
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
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
On 1/12/07, Martijn van Oosterhout wrote:
On Thu, Jan 11, 2007 at 02:35:13PM -0800, [EMAIL PROTECTED] wrote:
> I caught this thread about O_DIRECT on kerneltrap.org:
> http://kerneltrap.org/node/7563
>
> It sounds like there is much to be gained here in terms of reducing
> the number of user/ke
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
I caught this thread about O_DIRECT on kerneltrap.org:
http://kerneltrap.org/node/7563
It sounds like there is much to be gained here in terms of reducing
the number of user/kernel space copies in the operating system. I got
the impression that posix_fadvise in the Linux kernel isn't as good as
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
Hi everyone,
Here's a prototype for what I had in mind, the sections that will
probably be of most interest are pgsql and bizgres.
This link shows all tracked repositories:
http://folio.dyndns.org/repository/report
This link shows all tracked patches for pgsql:
http://folio.dyndns.org/patch/rep
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
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
On 1/4/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
>> > That also happens. The only way I can see of ensuring it does not
>> happen
>> > would be to auto-proc
On 1/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-04 at 09:09 -0500, Andrew Dunstan wrote:
> That also happens. The only way I can see of ensuring it does not happen
> would be to auto-process all patch submissions.
Sounds a good idea. Patch farm anyone? Auto apply/make check?
13 matches
Mail list logo
