RE: ACPI patch flow

RE: ACPI patch flow

[Brown, Len]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

> From: Jeff Garzik [mailto:jgarzik@pobox.com] 
...
> I definitely support the posting of plain patches...

Done.

In addition to pushing to the bkbits.net acpi-test-* trees,
I'll publish a plain patch every time I commit a cset to acpi-test-*
tree.

Like we've traditionally done on sourceforge.net, I'll continue to
publish a cumulative plain patch every time the acpi-release-* tree is
updated,
but these will not live on sourceforge.net any more.

The folks at kernel.org have graciously volunteered the space.

Here's the plan:
http://kernel.org/pub/linux/kernel/people/lenb/acpi/patches/README.ACPI
And attached for the curious is my handy bk.checkin wrapper script.

Thank you for your continued patience and support.

-Len

[-- Attachment #2: bk.ZIP --]
[-- Type: application/x-zip-compressed, Size: 780 bytes --]

RE: ACPI patch flow

[Brown, Len]

> ... uploads to sourceforge are time-consuming events.

Agreed -- need to get that GUI out of the loop...

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

I agree completely -- and will let you know what we end up with.

Thanks,
-Len

Re: ACPI patch flow

[Jeff Garzik]

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

ACPI patch flow

[Brown, Len]

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:

1. linux-acpi-test-*
Staging area for linux-acpi-release-*  This is where to go to try out
the latest integrated patch that is being tested in preparation for push
into the release tree.  In the past this was not visible, and so it
limited the ability of others to test the integrated patch w/o
integrating it all themselves, and led to surprises when changes came
out in the release that people may not have seen on the list.  Exporting
this will also allow me to give contributors quicker feedback when their
changes have entered the release pipeline.

2. linux-acpi-release-*
Same release trees as before, with same usage -- just added "release" to
the name.  As before, whenever we update these and release to 2.4 and
2.6 we'll also post post the plain patch to
http://sourceforge.net/projects/acpi

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.

Thanks,
-Len

Ps. The release tree has always been sync'd with the latest baseline for
each release; and this will still be the case.  But this makes it more
difficult for people to apply the latest patch to older trees.  So now
there is a 2.4.22 tree that is the (frozen) 2.4.22 plus only the ACPI
updates.  I'll apply 2.4 patches there and then push them forward into
the 2.4.23 tree.  We'll do the same with 2.6 when stable 2.6 baselines
emerge.