Difference between revisions of "CELF Open Project Proposal 2010"

From eLinux.org
Jump to: navigation, search
(Q and A)
(added links back to original project proposals)
 
(27 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Intoduction ==
+
== Introduction ==
The CELF Open Project Proposal is an process whereby members of the public can
+
The CELF Open Project Proposal is a process whereby members of the public can
 
submit to the CE Linux Forum ideas and proposals for projects that they think
 
submit to the CE Linux Forum ideas and proposals for projects that they think
 
should be worked on to enhance embedded Linux.
 
should be worked on to enhance embedded Linux.
  
Each year, CELF spends money on contract work to improve Linux, for use in
+
Each year, CELF spends money on contract work to improve Linux for use in
 
embedded systems.  Some of the projects we have sponsored in the past
 
embedded systems.  Some of the projects we have sponsored in the past
 
include Linux-tiny, DirectFB enhancements, smem, and Squashfs mainlining.
 
include Linux-tiny, DirectFB enhancements, smem, and Squashfs mainlining.
Line 14: Line 14:
 
== Process ==
 
== Process ==
 
=== Proposal format ===
 
=== Proposal format ===
 +
Each proposal should include the name of the proposer, a summary, and a description of the bugfix,
 +
feature or technology improvement that is being proposed.  The description should be
 +
brief (it can be as short as 1 or 2 paragraphs), but should include enough information
 +
to understand the scope of the proposal. It is important to list the expected benefit
 +
of the work.
 +
 +
The proposal should also list related or already existing work, and the expected scope of effort
 +
required to accomplish the goal. Finally, if you know of someone who might be interested or willing
 +
to work on the project, please include that as well.
 +
 +
The proposal should be in plain text, with URLs where possible to related discussions
 +
or existing work.
 +
 +
==== Sample ====
 +
Here is a sample proposal:
 +
<pre>
 +
Proposer: Tim Bird
 +
 +
Summary: Add bootchart boot logger functionality to busybox
 +
 +
Description: It would be nice to add bootchart functionality to busybox.
 +
Most distributions now have bootchart available as a package, which allows an
 +
administrator to see machine resource usage and process startup times, for
 +
the system bootup.  The existing bootchart boot logger, however, is a shell
 +
script, which consumes too much resources when running on an embedded platform.
 +
 +
The Android system includes bootchart boot logger functionality in it's
 +
'init' program.  It would be nice to include similar boot logging functionality
 +
built into busybox.
 +
 +
The feature would be to grab information from various /proc files, and save
 +
them into the files expected by bootchart, for a duration specified as a
 +
parameter to the 'init' applet of busybox.  The duration parameter could be
 +
passed as an environment variable from the kernel, copied from the kernel
 +
command line, or set in a specially-named file.  (Note that the latter
 +
two are used in Android.  It would probably be good to keep compatibility
 +
with the Android method of parameter passing, to avoid confusion.)
 +
 +
Note that the code for this in Android 'init' is licensed under the Apache
 +
license.  It's less than 400 lines of C code.
 +
 +
The benefit of adding this feature to busybox is that it would allow easy
 +
visualization of embedded system bootup information, for any system that
 +
uses busybox (which is pretty much all of them except for Android!)
 +
 +
Related work:
 +
* Bootchart - http://www.bootchart.org/
 +
* Android init and bootchart
 +
  * Usage guide: see http://elinux.org/Using_Bootchart_on_Android
 +
  * Code: see http://android.git.kernel.org/?p=platform/system/core.git;a=blob_plain;f=init/bootchart.c;hb=HEAD
 +
 +
Scope:
 +
This should take less than 2 weeks of development and test effort.
 +
</pre>
 +
 
=== Where to send the proposal ===
 
=== Where to send the proposal ===
 
Send your proposal to the celinux-dev mailing list, at:
 
Send your proposal to the celinux-dev mailing list, at:
celinux-dev@tree.celinuxforum.org.  To do this, you need to subscribe to the list.
+
celinux-dev (at) tree.celinuxforum.org.  To do this, you need to subscribe to the list.
 
You can do this via the [http://tree.celinuxforum.org/mailman/listinfo/celinux-dev celinux-dev mailing list web page].
 
You can do this via the [http://tree.celinuxforum.org/mailman/listinfo/celinux-dev celinux-dev mailing list web page].
  
 
An alternative is available (although not preferred), which is to send the proposal
 
An alternative is available (although not preferred), which is to send the proposal
 
to the the CE Linux forum project-proposal mailing list, at:
 
to the the CE Linux forum project-proposal mailing list, at:
project-proposal@tree.celinuxforum.org.
+
project-proposal (at) tree.celinuxforum.org.
  
 
Sending the proposal to the celinux-dev list is preferred, because other people
 
Sending the proposal to the celinux-dev list is preferred, because other people
 
can review the proposal, discuss it, and make suggestions.
 
can review the proposal, discuss it, and make suggestions.
  
=== Project Selection ===
+
=== Proposal Deadline ===
The CE Linux Forum will select the projects that it wants to fund.
+
Proposals for the initial 2010 project list will be accepted until '''December 20, 2009'''.
 +
 
 +
You may submit proposals after that, but they may not be considered for the
 +
initial project list.  Proposals submitted after December 20 may be used later in
 +
2010, or in future years' project lists, if the proposal is still relevant.
 +
 
 +
== Project bids ==
 +
Once the proposal period is complete, the Architecture Group of the forum
 +
will solicit bids for the projects, in order to determine the feasibility and
 +
cost of each project.
 +
 
 +
CELF will solicit bids via a variety of mechanisms, including working directly
 +
with individual contractors with whom CELF has worked previously, and issuing a call
 +
for bids from the general public.
 +
 
 +
The bidding period will be the first week of February, 2010.
 +
 
 +
See [[CELF project bidding instructions]] for instructions for submitting a bid, if you
 +
would like to be involved in contracting for one of the candidate projects this year.
 +
 
 +
== Project Selection and Completion ==
 +
The CE Linux Forum will select the projects that it wants to fund. Every member of CELF
 +
will have a vote on the projects.  The Architecture Group of the forum will collect the
 +
votes and determine the list of projects to fund for 2010.
 +
 
 +
Once the projects are selected, the Architecture Group  will work with contractors to actually perform the work.
 +
AG members or workgroup chairs will manage the projects to completion.
 +
Progress on the work will be reported in CELF's monthly newsletters and in relevant
 +
community mailing lists.
 +
 
 +
== The project proposals so far ==
 +
See [[Project Proposals for 2010]] for the proposals that have been made so far.
 +
 
 +
== Selected Projects ==
 +
I am pleased to report that the following projects were approved for funding
 +
by the CE Linux Forum for the year 2010.
 +
 
 +
# [[CELF_Project_Proposal/Add_LZO_compression_support_to_Squashfs | Add LZO compression support to SquashFS]]
 +
# [[Add_Pramfs_filesystem_to_the_kernel_mainline | Add PramFS filesystem to the mainline kernel]]
 +
# [[CELF_Project_Proposal/UBIFS_mount_time_speedups | Investigate UBIFS mount time problems]]
 +
# Mainline the YAFFS2 file system
 +
# Create a trace data format standard
 +
# [[CELF_Project_Proposal/Create_online_training_for_using_RT-preempt | Create online training for using RT-Preempt]]
 +
# [[Add_bootchart_boot_logger_functionality_to_busybox | Add bootchart support to busybox]]
 +
# [[CELF_Project_Proposal/Rework_ARM_architecture_support_in_U-Boot | Enhance support for ARM processors in U-Boot]]
 +
# [[CELF_Project_Proposal/Improve_kexecboot | Improve the kexecboot program]]
 +
# [[CELF_Project_Proposal/Add_-ffunction-sections_support_to_Linux_kernel | Mainline function-sections patches]]
  
 
== Q and A ==
 
== Q and A ==
Q. How is this different from other "open project" systems, like Google's "Summer of Code"?<br>
+
'''Q. How is this different from other "open project" systems, like Google's "Summer of Code"?'''<br>
A. Other systems often require that the submitter of the proposal be the one interested in doing
+
'''A.''' Other systems often require that the submitter of the proposal be the one volunteering to do
 
the work.  With CELF's Open Project Proposal, anyone who can think of a good idea can submit it,
 
the work.  With CELF's Open Project Proposal, anyone who can think of a good idea can submit it,
 
(possibly with hinting about someone who might be a good candidate to perform the work).
 
(possibly with hinting about someone who might be a good candidate to perform the work).
  
Q. How much money is CELF willing to spend on these projects?<br>
+
Of course you can also submit something you are interested in working on yourself, in the hopes
A. The exact amount shall remain a mystery.  However, usually, CELF budgets a bit more than  
+
that CELF will fund the work.
 +
-----
 +
'''Q. How much money is CELF willing to spend on these projects?'''<br>
 +
'''A.''' The exact amount shall remain a mystery.  However, usually, CELF budgets a bit more than  
 
$100,000 each year for contract work of this nature.  This is less than other similar
 
$100,000 each year for contract work of this nature.  This is less than other similar
 
projects, but is still enough to push some interesting projects forward, that make a  
 
projects, but is still enough to push some interesting projects forward, that make a  
 
difference over time.
 
difference over time.
 
+
-----
Q. Are you daft?  Why would you let other people suggest ways to spend CELF's money?<br>
+
'''Q. Are you daft?  Why would you let other people suggest ways to spend CELF's money?'''<br>
A. Hey, it's open source.  Good ideas can come from anywhere.  Note that CELF still
+
'''A.''' Hey, it's open source.  Good ideas can come from anywhere.  Note that CELF still
 
controls what projects get selected, and hence where the money will be spent. That's one
 
controls what projects get selected, and hence where the money will be spent. That's one
 
of the privileges of CELF membership.  However, CELF will publish the list of projects
 
of the privileges of CELF membership.  However, CELF will publish the list of projects
Line 48: Line 152:
 
entities may contribute money or resources to push some of the technologies or features
 
entities may contribute money or resources to push some of the technologies or features
 
forward, independent of CELF's contribution.
 
forward, independent of CELF's contribution.
 +
-----
 +
'''Q. Where will the proposals be published?'''<br>
 +
'''A.''' Right here on the eLinux wiki. See [[Project Proposals for 2010]]
 +
-----
 +
'''Q. How will CELF decide on contractors for these projects?'''<br>
 +
'''A.''' After collecting the proposals, CELF will solicit bids for contractors for these
 +
proposals.  In some cases, CELF may proactively contact individuals or groups they think
 +
would be good candidates for doing certain work (such as previous CELF contractors, or
 +
people already working on certain projects, who are available.
 +
 +
After talking to various contractor candidates, the CELF Architecture Group will select
 +
the contractors for the projects, contracts will be drawn up, and the work started.
 +
 +
[[Category:Project proposals]]

Latest revision as of 16:30, 11 May 2010

Introduction

The CELF Open Project Proposal is a process whereby members of the public can submit to the CE Linux Forum ideas and proposals for projects that they think should be worked on to enhance embedded Linux.

Each year, CELF spends money on contract work to improve Linux for use in embedded systems. Some of the projects we have sponsored in the past include Linux-tiny, DirectFB enhancements, smem, and Squashfs mainlining.

Usually, our process involves querying forum members about their desires and building a project list from that. This year, we are opening up the process and asking for your ideas and proposals as well.

Process

Proposal format

Each proposal should include the name of the proposer, a summary, and a description of the bugfix, feature or technology improvement that is being proposed. The description should be brief (it can be as short as 1 or 2 paragraphs), but should include enough information to understand the scope of the proposal. It is important to list the expected benefit of the work.

The proposal should also list related or already existing work, and the expected scope of effort required to accomplish the goal. Finally, if you know of someone who might be interested or willing to work on the project, please include that as well.

The proposal should be in plain text, with URLs where possible to related discussions or existing work.

Sample

Here is a sample proposal:

Proposer: Tim Bird

Summary: Add bootchart boot logger functionality to busybox

Description: It would be nice to add bootchart functionality to busybox.
Most distributions now have bootchart available as a package, which allows an
administrator to see machine resource usage and process startup times, for
the system bootup.  The existing bootchart boot logger, however, is a shell
script, which consumes too much resources when running on an embedded platform.

The Android system includes bootchart boot logger functionality in it's
'init' program.  It would be nice to include similar boot logging functionality
built into busybox.

The feature would be to grab information from various /proc files, and save
them into the files expected by bootchart, for a duration specified as a
parameter to the 'init' applet of busybox.  The duration parameter could be
passed as an environment variable from the kernel, copied from the kernel
command line, or set in a specially-named file.  (Note that the latter
two are used in Android.  It would probably be good to keep compatibility
with the Android method of parameter passing, to avoid confusion.)

Note that the code for this in Android 'init' is licensed under the Apache
license.  It's less than 400 lines of C code.

The benefit of adding this feature to busybox is that it would allow easy
visualization of embedded system bootup information, for any system that
uses busybox (which is pretty much all of them except for Android!)

Related work:
 * Bootchart - http://www.bootchart.org/
 * Android init and bootchart
   * Usage guide: see http://elinux.org/Using_Bootchart_on_Android
   * Code: see http://android.git.kernel.org/?p=platform/system/core.git;a=blob_plain;f=init/bootchart.c;hb=HEAD

Scope:
This should take less than 2 weeks of development and test effort.

Where to send the proposal

Send your proposal to the celinux-dev mailing list, at: celinux-dev (at) tree.celinuxforum.org. To do this, you need to subscribe to the list. You can do this via the celinux-dev mailing list web page.

An alternative is available (although not preferred), which is to send the proposal to the the CE Linux forum project-proposal mailing list, at: project-proposal (at) tree.celinuxforum.org.

Sending the proposal to the celinux-dev list is preferred, because other people can review the proposal, discuss it, and make suggestions.

Proposal Deadline

Proposals for the initial 2010 project list will be accepted until December 20, 2009.

You may submit proposals after that, but they may not be considered for the initial project list. Proposals submitted after December 20 may be used later in 2010, or in future years' project lists, if the proposal is still relevant.

Project bids

Once the proposal period is complete, the Architecture Group of the forum will solicit bids for the projects, in order to determine the feasibility and cost of each project.

CELF will solicit bids via a variety of mechanisms, including working directly with individual contractors with whom CELF has worked previously, and issuing a call for bids from the general public.

The bidding period will be the first week of February, 2010.

See CELF project bidding instructions for instructions for submitting a bid, if you would like to be involved in contracting for one of the candidate projects this year.

Project Selection and Completion

The CE Linux Forum will select the projects that it wants to fund. Every member of CELF will have a vote on the projects. The Architecture Group of the forum will collect the votes and determine the list of projects to fund for 2010.

Once the projects are selected, the Architecture Group will work with contractors to actually perform the work. AG members or workgroup chairs will manage the projects to completion. Progress on the work will be reported in CELF's monthly newsletters and in relevant community mailing lists.

The project proposals so far

See Project Proposals for 2010 for the proposals that have been made so far.

Selected Projects

I am pleased to report that the following projects were approved for funding by the CE Linux Forum for the year 2010.

  1. Add LZO compression support to SquashFS
  2. Add PramFS filesystem to the mainline kernel
  3. Investigate UBIFS mount time problems
  4. Mainline the YAFFS2 file system
  5. Create a trace data format standard
  6. Create online training for using RT-Preempt
  7. Add bootchart support to busybox
  8. Enhance support for ARM processors in U-Boot
  9. Improve the kexecboot program
  10. Mainline function-sections patches

Q and A

Q. How is this different from other "open project" systems, like Google's "Summer of Code"?
A. Other systems often require that the submitter of the proposal be the one volunteering to do the work. With CELF's Open Project Proposal, anyone who can think of a good idea can submit it, (possibly with hinting about someone who might be a good candidate to perform the work).

Of course you can also submit something you are interested in working on yourself, in the hopes that CELF will fund the work.


Q. How much money is CELF willing to spend on these projects?
A. The exact amount shall remain a mystery. However, usually, CELF budgets a bit more than $100,000 each year for contract work of this nature. This is less than other similar projects, but is still enough to push some interesting projects forward, that make a difference over time.


Q. Are you daft? Why would you let other people suggest ways to spend CELF's money?
A. Hey, it's open source. Good ideas can come from anywhere. Note that CELF still controls what projects get selected, and hence where the money will be spent. That's one of the privileges of CELF membership. However, CELF will publish the list of projects that it will fund, as well as the projects that were not funded. It is hoped that other entities may contribute money or resources to push some of the technologies or features forward, independent of CELF's contribution.


Q. Where will the proposals be published?
A. Right here on the eLinux wiki. See Project Proposals for 2010


Q. How will CELF decide on contractors for these projects?
A. After collecting the proposals, CELF will solicit bids for contractors for these proposals. In some cases, CELF may proactively contact individuals or groups they think would be good candidates for doing certain work (such as previous CELF contractors, or people already working on certain projects, who are available.

After talking to various contractor candidates, the CELF Architecture Group will select the contractors for the projects, contracts will be drawn up, and the work started.