[lsb-discuss] Examining the LSB buglist (help wanted)
shawn.zeng at oracle.com
Sun Feb 3 00:32:09 PST 2008
I am a member of technical staff of Linux engineering team in Oracle,
and assigned a task to engage with LSB project full time recently, and
this will be a long time effort.
It's my pleasure to do some useful works to help LSB project,but i don't
where and how to start, i don't know much about LSB now, so maybe it's
a good beginning to help you examine these bugs and eventually get involved
into the LSB development process.
So please feel free to assign me some task if you find there is lack of
I am good at C,Perl and Bash , not so good in C++ and python.
Wichmann, Mats D wrote:
> Currently, bugs.linuxbase.org is showing 319 open bugs.
> There are two main rollup bugs to observe here:
> bug 1025 is the rollup for LSB 4.0 (it has category
> rollups underneath it); collectively this set holds
> 147 of the open bugs.
> bug 1910 is the rollup for LSB 3.2 errata; collectively
> this set now accounts for two of the open bugs.
> Here are the actions I'd like to take in the near
> future. Anybody is welcome to help with this; we'll
> continue our "Friday is bug day on IRC" tradition, and
> we may continue with the Friday conference call on bugs
> which we held the last couple of months of the 3.2
> cycle to make sure progress was being made.
> 1. Examine the 4.0 bugs to make sure these are things
> we're likely to fix - that is, they still make sense.
> When a bug does not make the cut for a certain release
> it usually gets moved to block the next release rather
> than just being cut loose, but over time some issues
> may go stale, be solved other ways, or we might come
> to the realization that this issue will never reach
> a high enough priority to be addressed.
> 2. Examine the 170 bugs which do not block anything at all.
> If they're not targeted for being addressed in the
> next year, should they be? Should they still be open?
> Have these bugs gone stale? Are they maybe issues that
> should be tracked somewhere other than bugzilla (e.g.,
> sometimes long-term enhancement requests will languish
> in a bugtracker and do better being negotiated to go
> onto an "Issues from ISVs" list or something similar).
> Issues about the LF/LSB website used to go here but
> they're almost certainly better tracked somewhere else now.
> 3. Make sure the information in the bugs is up to date.
> If the state has changed, either through action inside
> the project or outside events, let's get that reflected.
> 4. When we have finished looking at what should really
> be on the 4.0 buglist, we'll prioritize, this time
> actually using the bug priorities, to see what needs
> to be addressed near-term, what can be done a little
> later, etc.
> Along the way, when we're in there poking at the bug
> contents, we'll look at some of the suggestions made on
> this list for being able to get better information more
> quickly out of the bugzilla.
> Please help if you can, especially if you're a bug owner -
> if there are bugs you should not be owning as your role
> has changed, etc. please give them away. If there's no
> obvious owner give them to mats at freestandards.org and I'll
> figure out an owner. But also for bug you don't own -
> maybe ones you've reported them, or commented on them,
> or othrwise expressed an interest. Let's get everything
> freshened up!
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
More information about the lsb-discuss