All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	"Grover,
	Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: ACPI patch flow
Date: Wed, 10 Sep 2003 16:23:33 -0400	[thread overview]
Message-ID: <3F5F8845.9080405@pobox.com> (raw)
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE009FD58-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>

Brown, Len wrote:
> I've re-named the linux-acpi* tree to be linux-acpi-release*; and made
> the staging area for the release tree visible -- calling it
> linux-acpi-test*
> 
> So a 2 stage release is now visible on the net:

cool!


> As before, the BK trees live here:  http://linux-acpi.bkbits.com  If
> there is demand for plain patches of the _test_ tree we can probably
> also export those on http://sourceforge.net/projects/acpi too, but as
> the test tree will change more often, those updates would have to be
> on-demand or on significant events.

I definitely support the posting of plain patches, and strongly 
encourage it.  We don't want any barriers at all to people testing the 
latest ACPI fixes.

May I make a humble suggestion?  :)  Whenever net driver stuff gets send 
off, I'll often run a prepared script which will create a GNU diff 
against mainline, gzip it, and upload it to ftp.kernel.org.  That gives 
the non-BK users patches to play with.

I first considered posting these net driver patches on sourceforge 
(project: gkernel), but uploads to sourceforge are time-consuming 
events.  You have a upload to an FTP site, then fill out a bunch of 
forms and click a bunch of buttons.  It's a system that _discourages_ 
frequent software postings, IMO.

So, my suggestion is to get an account on some web/ftp site 
(kernel.org?) and create a script that combines two tasks (bk push and 
GNU patch upload) into a single command you run on your local Linux box. 
  Properly scripted, posting a patch shouldn't be any more work than 
pushing to your new test tree.  And IMHO you will reap the benefits.

	Jeff

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jgarzik@pobox.com>
To: "Brown, Len" <len.brown@intel.com>
Cc: acpi-devel@lists.sourceforge.net, "Grover,
	Andrew" <andrew.grover@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: ACPI patch flow
Date: Wed, 10 Sep 2003 16:23:33 -0400	[thread overview]
Message-ID: <3F5F8845.9080405@pobox.com> (raw)
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE009FD58@hdsmsx402.hd.intel.com>

Brown, Len wrote:
> I've re-named the linux-acpi* tree to be linux-acpi-release*; and made
> the staging area for the release tree visible -- calling it
> linux-acpi-test*
> 
> So a 2 stage release is now visible on the net:

cool!


> As before, the BK trees live here:  http://linux-acpi.bkbits.com  If
> there is demand for plain patches of the _test_ tree we can probably
> also export those on http://sourceforge.net/projects/acpi too, but as
> the test tree will change more often, those updates would have to be
> on-demand or on significant events.

I definitely support the posting of plain patches, and strongly 
encourage it.  We don't want any barriers at all to people testing the 
latest ACPI fixes.

May I make a humble suggestion?  :)  Whenever net driver stuff gets send 
off, I'll often run a prepared script which will create a GNU diff 
against mainline, gzip it, and upload it to ftp.kernel.org.  That gives 
the non-BK users patches to play with.

I first considered posting these net driver patches on sourceforge 
(project: gkernel), but uploads to sourceforge are time-consuming 
events.  You have a upload to an FTP site, then fill out a bunch of 
forms and click a bunch of buttons.  It's a system that _discourages_ 
frequent software postings, IMO.

So, my suggestion is to get an account on some web/ftp site 
(kernel.org?) and create a script that combines two tasks (bk push and 
GNU patch upload) into a single command you run on your local Linux box. 
  Properly scripted, posting a patch shouldn't be any more work than 
pushing to your new test tree.  And IMHO you will reap the benefits.

	Jeff




  parent reply	other threads:[~2003-09-10 20:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-10 19:01 ACPI patch flow Brown, Len
2003-09-10 19:01 ` Brown, Len
     [not found] ` <BF1FE1855350A0479097B3A0D2A80EE009FD58-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2003-09-10 20:23   ` Jeff Garzik [this message]
2003-09-10 20:23     ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2003-09-10 21:12 Brown, Len
2003-09-10 21:12 ` Brown, Len
2003-09-27  2:18 Brown, Len
2003-09-27  2:18 ` Brown, Len
2004-02-02 18:46 Len Brown
     [not found] ` <1075747579.2394.108.camel-D2Zvc0uNKG8@public.gmane.org>
2004-02-03 12:28   ` Pavel Machek
     [not found]     ` <20040203122832.GA1405-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2004-02-03 13:01       ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F5F8845.9080405@pobox.com \
    --to=jgarzik-e+axbwqsrlaavxtiumwx3w@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.