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
next prev 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.