Re: Ubuntu development - joining...

2007-11-03 Thread Tim Hull
 The best approach is to search a project/issue that you are interested
 in, which seems to be improving the laptop experience. There is also a
 lengthy document from Andreas Lloyd which lots of contacts:
 https://wiki.ubuntu.com/ContributeToUbuntu


Thanks for the info.

The Ubuntu membership is more a kind of reward for contributing a lot to
 Ubuntu and expect of getting a nice email address you cannot do a lot
 with it.

 You will get commit access (motu/core-dev) if you have proved to be a
 trustworthy and productive member of the community and the corresponding
 privileges will help you to improve your work flow a lot. I don't think
 that this is the case yet.


I wasn't implying that I was asking for commit access, just that I was
interested in working toward that.

If you have a patch just nag the people on IRC about it.


OK - I haven't always had the best of luck there, though...

All of the above mentioned bugs are very hard to reproduce and a likely
 cause is not the relevant part of the code that has to be fixed or even
 a solution. Furthermore it seems that in general the hardware support of
 the MacBook doesn't seems to be very good: Perhaps some ACPI issues.


What about #137598?  That one has a patch, and several other people
experiencing the issue as reported in the bug.
Also, #147883 has an upstream patch.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Non-critical bug fixes/new hardware drivers in stable releases?

2007-08-31 Thread Tim Hull

 
  Backporting changes is risky. Ubuntu makes the decision that security
  fixes are worth the risk of backporting. If you are talking about
  changes that are available in later releases, then the affected users
  are able to upgrade. In my opinion, it is more important that we don't
  break the machines of people for whom everything is currently fine.



I'm not talking about new features (aside from possibly new drivers).  I'm
mainly talking about bugs that, while not security/data loss bugs, are still
significant annoyances. The HAL bug I mentioned earlier in the thread is the
perfect illustration of what I mean.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Non-critical bug fixes/new hardware drivers in stable releases?

2007-08-30 Thread Tim Hull
Hi,

I've been lurking/occasionally posting here for a while, and I would like to
bring up an issue that has been a real annoyance in my attempted use of
Ubuntu (as well as other Linux distributions, notably Debian) this summer.

In short, while I feel that Ubuntu has made real progress with regards to
desktop Linux - comparing Hoary and Feisty (the last release I had used
prior to this summer) is like night and day.  More works out of the box,
it's FAR easier to get all the popular non-free codecs, and it generally
feels like a modern desktop operating system.

However, in installing Ubuntu I ran into a whole slew of issues that, while
not will make your system explode/lets hackers in/causes data loss bad,
are quite annoying nevertheless.  Some examples include:

1.  Many USB storage devices can't be properly unmounted using the GUI.  One
must use the console or use non-optimal workarounds (that are distinctly
UNSUPPORTED) to fix this.  The bug in particular can be found at
https://bugs.launchpad.net/ubuntu/+bug/99538

2. My laptop (a MacBook, don't laugh :) ) won't suspend-to-RAM with the
default kernel.  To be precise, it will suspend, but it will not resume :)
This is fixed in newer kernels (such as those in Gutsy) and can be worked
around with a kernel recompile in 2.6.20.  However, one must either compile
a kernel or use apt-pinning with Gutsy sources to use this fix - a decidedly
unsupported and nonintuitive fix.

3. Many other examples that I can't think of off the top of my head - though
one may see many of these by looking at the Howto configure XYZ wiki
pages.  Words such as recompile, add this repository, etc etc seem to be
a constant occurence here.  This is especially apparent when it comes to new
hardware that has drivers, albeit ones that weren't ready as of the stable
release.

What these issues have in common is that, under current policy (which calls
for updates for security/data loss type issues ONLY), there is little or no
chance of having them fixed in the stable release.  While I can see the
merit of keeping changes to stable to a minimum, it seems like the
existing policy of Ubuntu (and many distributions - I'm not blaming Ubuntu
in particular) is leaving many users out in the cold with regards to their
issues until the next release.

I can see this policy for a server or enterprise desktop (and thus the LTS
releases), but not a normal desktop.  For desktop users, it ends up making
them fix some bugs/hardware support issues themselves using the command
line/third-party repositories/building from source - which is something that
should be avoided.  Has there been any consideration to easing the stable
release updates policy to accommodate issues like these?

I'm not necessarily advocating that the stable release receive every update
under the sun (certainly not feature-only updates), but it seems like
allowing more bug fixes/new drivers to enter the stable release would be
beneficial to many end users. I think that many users are probably turned
off by the recompile, add this unsupported software, hack this code, etc
etc (I know this is what always ends up pushing me away from Linux) and
this would go a long way towards alleviating this.

Any comments?  I'm especially wondering what developers think of this
issue...

Tim
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Ubuntu development...

2007-08-25 Thread Tim Hull

 The fact that you submit bug reports and do not follow up / patch them
 yourself
 shows a severe disinterest in *really* helping ubuntu and (like most
 new devel's in all projects) just want to focus on the hot-dog stuff.


I do follow up - in fact, I've often posted additional info on my bug
reports as to the origin of the issue/suggestions as to what could be done.
 I may not have the solution to everything, but that doesn't mean that I'm
just being lazy or just focusing on the hot-dog stuff.  Maybe it means
that for you, but I've submitted bugs/ideas to other projects (including
*Debian*, of all distributions) and have received plenty of response.


 2) RTFM. Please. Coming onto the mailing list and asking for manual
 locations makes me want to knife myself. Yes it could be clearer, but
 you are not asking for help or clarifying a point, your just being
 lazy.


I'm not asking for something trivial - I'm asking how to provide input/ideas
regarding key components of the system.  It's perfectly clear how to do
MOTU/Bug Squad/etc - it's NOT clear how to go about suggesting changes to
the main desktop setup.  I've looked countless times on Launchpad and have
remained stumped - RTFM really doesn't help one bit.


3) Before you start working on MAJOR new features, why not help fix
 bugs and other common problems first? Wouldn't these be more benficial
 and a better learning process than Making the default system look
 better?. BTW the way it renders fonts is entirely appropriate: Most
 people get used to MS's crappy way of sub-sampling fonts to make them
 look sharper.


In many of the cases I've discussed, I'm not necessarily talking about
coding a major new project from scratch - I'm talking about integrating
already existing code into the system, investigating changes in default
settings, etc.  Yes, I certainly would work on the smaller bugs/issues as
well - and I already know where to go for that (Bug Squad, MOTU, etc etc).
 However, it's unclear where to go with basic desktop issues/ideas, other
than to file a bug in Launchpad, provide all the info you can, and wait.



Do any Ubuntu developers care to comment?  I'd like to contribute, but I'm
beginning to feel like I can't do so in any meaningful way outside the
universe and Launchpad bug reports (which, even when I provide extensive
info and narrow the problem to something fairly specific, don't tend to get
much response).



Tim
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Ubuntu development...

2007-08-24 Thread Tim Hull
Hi,

(I know I may have brought up some of this before, but it was in the middle
of a Tribe freeze and I wasn't exactly clear regarding what I had to say.
Please excuse this...)

I'm currently a senior at the University of Michigan, majoring in (what
else) Computer Science, and I've been toying with Linux/Open Source for some
time now.  While it hasn't always been my primary OS, I have regularly
tinkered with it and generally know how to deal with tricky issues (kernel
compilation, backporting software, working around bugs, etc etc).  I've
always been partial to Debian-based distributions - RPMs I can't stand, and
don't even get me started on Gentoo.

Anyway, I'm somewhat interested in Ubuntu development.  However, while I
have been able to uncover plenty of info about MOTU, that's not where most
of my interest lies.  My interest lies in mostly working on issues that
effect the usability of the main system for an average user - in short, Bug
#1 issues.  Some things that come to mind include:

* Making iPods and music library management work properly without extensive
manual tweaking (rhythmbox doesn't quite cut it here)

* Make laptop suspend/resume/power management work well with sane
out-of-the-box settings (getting better, but still needs tweaking)

* Eliminate the need to edit configuration files for commonly-changed
settings (synaptics touchpad, I'm looking at you...)

* Making the default system look better - especially in the area of font
rendering (the default hinting is *ugly*)

* Making software upgrades work in a more sane way - in particular making it
easier to update individual components of the system without updating
everything (why, oh WHY, do I need to update half the system to get
something - even simple things - from unstable)

I'm curious - where can I help out?  I do file some bugs on launchpad, but
hardly ever get any followup - understandable, given that many of the issues
at hand aren't bugs per se.  I have indeed come up with some specific ideas
to help resolve the issues at hand, but have yet to find a reliable way to
actually propose these ideas and discuss them with developers.

Tim
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Getting in touch with development teams...

2007-08-08 Thread Tim Hull
Hi,

I've been using Linux on and off for some time now, and have been looking to
get involved in development/testing on the distribution level.  Anyway,
after looking at many distros and reading about them, it is obvious that the
ones that are most appealing to me are Ubuntu and Debian - which obviously
share a common heritage (Ubuntu is based on Debian sid).

In using Ubuntu, I've actually come up with a few ideas/suggestions
involving the core system (i.e. - not MOTU material).  In particular, I've
been looking into a few laptop-specific issues (power management, odd issues
with C-states, etc), and additionally some issues with multimedia support
and how it works on Ubuntu.  I know about Launchpad and have filed bugs on
there, but would like to get directly in touch with the teams working on
these issues.

I've noticed with Debian that the development is mostly done out in the open
on the mailing lists and the bug tracking system with direct contact between
developers and users.  However, I haven't noticed this so much with Ubuntu.
I know that the Core Development Team exists - do they have their own,
closed mailing list?  Is this development done in house (i.e. physically) at
Canonical offices?

Could somebody fill me in on this?  I'd like to help/offer suggestions on
these issues directly with the teams involved.  I've tried e-mailing a few
people (in particular, those responsible for laptop issues and multimedia),
but have not received a response.

Tim Hull
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Updates post-release/freeze

2007-07-30 Thread Tim Hull
 I know my last thread was confusing to some developers with regards to my
desire for a greater availability of updates post-release.  I thought I'd
clarify - I'm not primarily thinking of LTS releases, and I'm not suggesting
that a large number of supported components be version-updated between
releases.

However, I do see the desire for some updates to be available between
releases, to a greater extent than backports currently handles (for
instance, backports currently has no interest in making any new kernels
available, and only has a limited number of packages).  In many cases, users
who need something that is not in the stable release but which is available
(for instance, kernel fixes which came after the stable release, or a bugfix
for a universe application) are having to compile from source.

1)  For supported components, Stable Release Updates could be expanded to
incorporate all significant bugfixes that can be done in a sane and safe way
(i.e. without major version bumps).  This could include supporting new
hardware (like new revs of a wireless chipset) as well as fixing
miscellaneous issues like suspend-to-RAM breakage.  If a major version rev
is necessary, this could be included but not installed by default.

2) For unsupported components, Universe (and multiverse) could be updated on
a rolling basis after release.  This could be for mere feature updates -
though they would still have to not require new versions of main
components. Components in main could have unsupported updates in universe,
though these would have to install alongside the main packages (firefox3,
for instance, could be a Firefox 3 package).  A universe freeze could be
maintained, though updates after the fact would merely go in
universe-updates instead of universe.  This would supplant the existing
backports system, and would actually parallel what FreeBSD does with its
ports.

Devs, I'm curious to hear your thoughts.  Is there anything I can do as a
user to help bring about anything like this?

Once again, thanks for the nice distro...

Tim
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Re: Updates post-release/freeze

2007-07-30 Thread Tim Hull


 This all takes more resources.  In Universe and Backports both we do not
 have
 sufficient communicty involvement to support the current demand.  IMO any
 proposal for more $STUFF that isn't paid for should also have some
 thoughts
 about where the labor to do the work is going to come from.



 The idea would be to have the stable universe updated in much the same way
as the unstable universe is.  I.e. instead of building new updates against
just gutsy, they would built against Feisty and Gutsy, with the Feisty
updates going to universe-updates.  There could be an RC bug delay in
having them built for the stable release - think the Debian testing
strategy.  I understand why you suggest this can't be done, though.

Anyway, I don't mean to sound rude in any respect.  I will admit, I tend to
sometimes think up ideas without truly thinking over the logistics.  I do
intend to get involved somehow - possibly in SRU or Backports (if not for
Ubuntu, then for Debian).  I appreciate what has been done so far, and I
know you developers are doing a lot as-is. Thank you...

Tim
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


Getting involved in Ubuntu development/testing...

2007-07-16 Thread Tim Hull

For the past several years, I have dabbled in Linux/GNU/open source/free
software, starting in 1999 when I managed my first Linux install, which was
Debian 2.0 (now THAT was dependency hell - no apt back then).  Since then, I
have always been partial to the Debian way of doing things, as compared to
the world of RPMs or building everything from source.  However, I have been
frustrated by Debian's somewhat-slow pace of development, occasional
hostility towards new users (both in the system sense and community sense),
and the free software or no software mentality some have in the
world-of-Debian.  I do, however, greatly appreciate and respect the
contributions the Debian Project has made - it's truly quite amazing for an
all-volunteer project.

Now, Ubuntu has taken the Debian base and added many things to it that I
like - regular releases, support for hardware that doesn't have 100% Free
drivers, ease of use, and a general friendliness towards new users in
general.  As such, I have been following Ubuntu since it first came out.
However, though Ubuntu has done a great job overall, I still see many issues
that need desperate attention - laptop support, iPod support, and ease of
application installs/upgrades outside of distribution releases, to name a
few.  As a result, I have ended up flip-flopping between Ubuntu and Mac OS X
- which I actually started using after I got sick of Windows and couldn't
get ACPI going well in the very early days of Ubuntu.  On OS X, however, I
sorely miss the sense of community and the world of open source/free
software from Ubuntu.

Anyway, I am very interested in helping out with Ubuntu in any way I can.
While I can't code C very well, I have extensive experience beta-testing
software for a couple proprietary OS vendors.  I also have a large amount of
general experience, and have managed to do things as weird as putting the
home partition on an HFS+ volume (to keep files in sync with OS X).  Also, I
have begun filing bugs in Launchpad for Ubuntu.  However, I feel like I can
do much more - as in many of these cases, I have pinpointed the source of
the problem and feel that something could be done about it. Additionally, in
using Ubuntu I have come up with many of my own ideas for improvements.
Filing a bug in Launchpad, however, doesn't seem to result in much in any of
these areas.

How can I get involved?  I've seen some things about the Bug Squad, the
Laptop Testing Team, and Masters of the Universe, and I'm not exactly sure
how it all works.  In particular, I'm interested in helping report and fix
bugs (though not in the raw, in-depth coding sense), possibly packaging some
software (I noticed xcalib - a useful CLI tool for adjusting your color
profile/gamma in X using a profile - isn't packaged), and helping identify
issues with Ubuntu and possible solutions to them (such as the
afore-mentioned iPod support).

One issue of mine is that I am somewhat limited in my testing hardware -
currently I have one system - a MacBook - and have waffled between running
Ubuntu natively and on VMware in Mac OS (mostly due to power management
issues). At the moment, I don't run Ubuntu full-time, but I hope things
mature to the point where I feel I can do so without giving up anything.
Furthermore, I want to help towards that goal.

Comments, suggestions, etc welcome...  I'm curious from hearing from Ubuntu
developers on this..
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss