Kernel.org bk2 was the first bk snapshot with prism54 driver in it.
bk4 is out already and some changes were already made too.
I was going to make some cvs repository changes today @ prism54.org
in order to attempt to keep a synced up repository for development
but I realize this is just not going to be possible. You can't stop
what goes on in the kernel tree and keeping our repository in-sync
with the latest bk snapshots is just too much pain in the ass to even
consider we'd be able to work out of a prism54 tree and write valid
patches.
At this point I think we can safely say the the prism54 project has
been complete. Although forced upon, this is not necessarily
a bad thing. The 2.6 prism54 driver is just going to take a life of
its own now and its out of our hands what goes on with it.
The 2.4 driver is still in our tree and not sure if it'll go into 2.4.
We'll see. Anyway for now the prism54.org project can still be home to further
advances of the driver/support. Please feel free to CC patches to us
([email protected]) for review in e-mails sent to netdev / Jeff / kernel
mailing lists for peer review and updates. That's what we're now here for.
If you have other large prism54 contributions you can use prism54.org as your home.
As for USB support maybe now we can put this as high priority while
other aspects of the driver are hammered by other developers. If you
will like to still follow up on the latest on prism54 development,
prism54.org will be the home for it. Just remember that it'd be just easier
for you to work out of kernel.org bk snapshots when writing patches
since we're no longer the home of the latest prism54 src.
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
There still needs to be a central "maintainer" of prism54, someone who
sends patches either directly to me, or via Jean to me (maintainer's
choice). Ideally, it is best to funnel patches from everybody through
driver-maintainer -> subsystem maintainer -> Marcelo|Andrew|Linus. That
only breaks down when the driver or subsystem maintainer is too slow,
and doesn't follow the "release early, release often" precept :)
Open source is about lack of control, and trusting that community and
consensus will produce superior software over the long run... but lack
of control doesn't mean lack of organization :)
Jeff
On Tue, Mar 16, 2004 at 01:01:31AM -0500, Jeff Garzik wrote:
> There still needs to be a central "maintainer" of prism54, someone who
> sends patches either directly to me, or via Jean to me (maintainer's
> choice). Ideally, it is best to funnel patches from everybody through
> driver-maintainer -> subsystem maintainer -> Marcelo|Andrew|Linus. That
> only breaks down when the driver or subsystem maintainer is too slow,
> and doesn't follow the "release early, release often" precept :)
>
> Open source is about lack of control, and trusting that community and
> consensus will produce superior software over the long run... but lack
> of control doesn't mean lack of organization :)
>
> Jeff
Well in that case we'll also act as the "official" prism54 patch
recipients/senders. And by "we" I mean any of the prism54 developers
listed on our project page. We can do this but we can only do this if the
patches are sent to *us* based on clean bk trees. It's important that
patches are sent to *us* prior to inclusion in the kernel since this
driver is not the normal 1-file driver. If a patch goes into the driver
in the kernel tree but not ours it's going to be a pain mantaining our
tree / writing patches for you (as was done just now), specially since
we're still a heavily active driver project.
So for now then, I'm going to update our CVS repository to match the
kernel tree and we'll soon send you patches with the latest changes.
Please only accept then patches/changes for the driver if its passed through us (if
this is possible). It's not that that we don't want people to contribute
it's just that this is the way it has to be in order to make our live's
easiers as mantainers of the driver.
I'm already subscribed to the netdev list and I'll keep my eyes open for
any wide-kernel changes/patches and apply them too. I'll ask the others
to do the same.
Is this an OK plan?
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
Luis R. Rodriguez wrote:
> Well in that case we'll also act as the "official" prism54 patch
> recipients/senders. And by "we" I mean any of the prism54 developers
> listed on our project page. We can do this but we can only do this if the
> patches are sent to *us* based on clean bk trees. It's important that
> patches are sent to *us* prior to inclusion in the kernel since this
> driver is not the normal 1-file driver. If a patch goes into the driver
> in the kernel tree but not ours it's going to be a pain mantaining our
> tree / writing patches for you (as was done just now), specially since
> we're still a heavily active driver project.
That's not scalable, since the upstream tree should not bottleneck on
another tree.
If "prism54 dev team" are active maintainers, and respond to feedback
and users patches, _most_ patches will come from you. But this is never
a guarantee... Also, you should expect that developers often work
exclusively with the upstream tree, so patches from outside developers
will be diff'd against latest upstream BK.
I think we all want the same thing... a decent prism54 maintained by
folks that know it best. For the prism54 dev team, that means keeping
track of any upstream changes. For the Linux community's part, the
standard etiquette is to mail a patch to the driver's maintainer.
Sometimes this etiquette is bypassed for stuff like: first-time merges,
changes that affect large numbers of drivers (of which prism54 just
happens to be one of) in Linux, and simple build fixes from architecture
maintainers.
Jeff