Karmic Koala open for development
| From: | Martin Pitt <martin.pitt-AT-ubuntu.com> | |
| To: | Ubuntu Development Announcements <ubuntu-devel-announce-AT-lists.ubuntu.com> | |
| Subject: | Karmic open for development | |
| Date: | Tue, 28 Apr 2009 10:33:50 +0200 | |
| Message-ID: | <20090428083350.GS1921@piware.de> |
Hello world, Following a brief period while we got the toolchain into shape, the Karmic Koala is now open for general development. Please remember to wear your seat-belt, and remember that bugs in the rear-view mirror may be closer than they appear. Automatic syncs from Debian will begin shortly. The release schedule for Karmic is available at https://wiki.ubuntu.com/KarmicReleaseSchedule . To summarise the next few months, we expect to be able to produce the first milestone in mid-May, to cease automatic syncs from Debian towards the end of June, and to enter feature freeze at the end of August. We do not recommend that users upgrade to Karmic at this time; it is likely to be in very considerable flux until the initial round of merges is complete. As ever, any developers wishing to take the plunge at this early stage should ensure that they are comfortable with recovering from anything up to complete system failure. Good luck! -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-an...
Posted Apr 29, 2009 6:41 UTC (Wed)
by muwlgr (guest, #35359)
[Link] (22 responses)
Posted Apr 29, 2009 11:46 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Apr 29, 2009 16:19 UTC (Wed)
by muwlgr (guest, #35359)
[Link]
Posted Apr 29, 2009 12:15 UTC (Wed)
by jengelh (guest, #33263)
[Link]
Posted Apr 29, 2009 13:21 UTC (Wed)
by tajyrink (subscriber, #2750)
[Link] (6 responses)
There are far better ways to get attention to specific bug reports than yelling at message boards, but still it seems to be the most popular method that is tried.
At least my interest goes to 0 at the moment I feel someone is accusing generally everyone for not fixing their pet bugs, as if every developer would be in existence only for pleasing specific users. And I cannot imagine it helps to motivate even a paid developer for the specific package, if there is such (often no).
Posted Apr 29, 2009 16:28 UTC (Wed)
by muwlgr (guest, #35359)
[Link] (5 responses)
Posted Apr 29, 2009 19:50 UTC (Wed)
by tajyrink (subscriber, #2750)
[Link] (1 responses)
But you are definitely right in that Ubuntu can't keep up with the bug reports. It's just that it's exactly not anyone's fault, so there is not exactly anyone who could be summoned to help on the matters of fixing bugs. If there would be more development community, more bugs would get fixed. If it would be made harder to file bugs, less bugs will be filed but maybe signal-to-noise ratio would increase.
It's quite often that a random bug is not acted upon. One of your bugs is an universe bug, so it's completely on community's shoulders, and the community that actually maintains 90% of the packages is Debian (which also has enough of tens of thousands of open bugs). The others are too also largely community's responsibility more often than not, if they do not affect a big bunch of people in a significant way. There is currently ca. 1000 open bugs per one paid developer, so they need the community effort to collect bugs, mark as significant and combine duplicates.
It is _unfortunately_ so that the better you understand how bugs are triaged, combined, noticed, tagged, the better the chances there will be something done about it. Therefore it is not generally very useful to just file a bug, bookmark it and start hitting refresh. Even getting other affected people to click "this affects me" and especially finding any duplicate bug reports might help. If the bug is not very precise, with all the relevant logs (and preferably with patch attached or pointers to other places where the problem is described), it's not necessarily popping up in anyone's radar. And if it does not pop up anywhere, it may be that nearly no-one ever even reads it.
One more aspect is that some packages in main are more watched than others. Therefore it's useful to check what's happening with other bugs in the same package, and of course also if there's an active maintainer that could be contacted directly.
Posted Apr 30, 2009 2:26 UTC (Thu)
by TRS-80 (guest, #1804)
[Link]
Posted Apr 30, 2009 23:29 UTC (Thu)
by jmspeex (subscriber, #51639)
[Link] (2 responses)
Posted May 2, 2009 20:36 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Take my own "pet bug" in GCC: PR3187. It was
reposrted 2001-06-14. Lifetime ago. And it's STILL unfixed. But at least
it's there and I check it's status from time to time. Hopefully it'll be
fixed at some point. In Ubuntu I'm forced to constantly renew my bugs if they are not fixed -
since they are constantly closed as "duplicate", "invalid", or some other
ridiculous mark. But of course to expect that any minor bug (and any bug with package
from universe is minor by definition) will be fixed in three days is
strange...
Posted May 5, 2009 11:53 UTC (Tue)
by jmspeex (subscriber, #51639)
[Link]
Posted Apr 29, 2009 15:03 UTC (Wed)
by zooko (guest, #2589)
[Link] (10 responses)
https://bugs.launchpad.net/ubuntu/+source/courier/+bug/29...
(Your LWN name has some letters in common with "Wladimir Mutel".)
I can think of a few things you could do to move these tickets along. The thing that moves them along the furthest, of course, is probably submitting a patch or test cases that spell out the problem as specifically as possible. Another thing you could do is post a "Me too" comment showing details of how the bug affects you. "Me too" comments in discussions are rarely welcome, but I think in bug reports they can be, if they are accompanied by examples or other details, because they help show that the same or similar bug happens on a different system, and they show that someone else cares enough to write a polite and detailed comment about it. One of the easiest things you can do is that launchpad has a "This bug affects me" feature. I don't know what happens if you click that link, but I assume that somewhere there is a count of users who have clicked on that link on that bug, and this too would probably help developers prioritize their work.
Posted Apr 29, 2009 16:42 UTC (Wed)
by muwlgr (guest, #35359)
[Link] (8 responses)
You see, I was thinking that Ubuntu would be slightly better than Debian-unstable for my server configurations. And you know, my use pattern for Ubuntu is slightly different that 'Boot LiveCD on a system with empty disk, click Install, wait for the process to complete' (which seems the only pattern they actually test). Sometimes I actually upgrade my systems from version N to version N+6months by update-manager. Don't know what to choose now. Debian-unstable brings its own long-standing breakages. Debian-stable gets old with the time to the next release. Ubuntu releases more often but it loses track of bugs fixed in Debian starting from D.I.F. and up to until the release.
Posted Apr 29, 2009 17:01 UTC (Wed)
by larryr (guest, #4030)
[Link]
I have no idea how much testing it receives, but since Gutsy I have used the "alternate" disk with the "install a command-line system" option, and it has always worked fine for me. It seems to be essentially the same as the Debian installer.
Posted Apr 29, 2009 17:49 UTC (Wed)
by sbergman27 (guest, #10767)
[Link] (6 responses)
Please elaborate. There seems to be little enough interest in any of your listed bugs, judging from the notable lack of participation in the launchpad threads. I would suggest that your time would be better spent posting to launchpad than conducting a negative PR campaign in public forums. Isn't this at least your 3rd recent post here along these lines?
Posted Apr 29, 2009 23:13 UTC (Wed)
by muwlgr (guest, #35359)
[Link] (5 responses)
LP:298085 - I had a system with Postfix as smtp MTA and Courier as pop3/imap server. Postfix was configured to use Courier's maildrop program as a local MDA for virtual domains. Having upgraded from Ubuntu 8.04 to 8.10, and from Courier maildrop 0.58 to 0.60, I found that maildrop was recompiled without Courier authlib support, thus losing the ability to deliver to the virtual domain mailboxes configured in Courier's userdb. This behaviour is still kept in Ubuntu 9.04.
LP:352622 - the fix is trivial. Just a recompile. But who would recompile this thing, me ? And how big is my chance to get an updated package during the lifetime of Ubuntu 9.04 ? And similar things happen not the first time, with other packages before. The simpler is the fix, the longer you have to wait for update from Ubuntu maintainers. The more you have to rely on your own mind and hands. Which defeats the whole purpose an benefit of distribution-making, I think.
LP:366967 - don't know if it is worth to copy the whole description here. All symptoms are visible. Mindless race to a faster boot. Undermaintainment of an once-critical subsystem. Who needs this ifupdown and interfaces(5), we solve everything with network-manager now, right ? (wrong, I have some complex server and router configs). I propose a working fix there, and would you guess my (and other's) chances to get an useful update during Jaunty lifetime ? Zero or more ?
Debian:513102 - the fix is trivial again. Just give some review to the bugs fixed in Debian after Debian-Import-Freeze happened in Ubuntu, and soon before your release. Just don't try to keep all Debian bugs frozen for about 5 months. I doubt heavily that Ubuntu adds any vaulable specific patches to 'squid' package, and that moving from version 2.7stable3 to 2.7stable6 would bring more breakage than keeping the bug 513102 unfixed.
I hope I have certain ground to state my griefs here and in the Launchpad.
Posted Apr 30, 2009 0:51 UTC (Thu)
by sbergman27 (guest, #10767)
[Link] (4 responses)
#35622 is on pptpd. Which is, at least, an actual Canonical-maintained package. But the problem does not look major, and it's hardly an old bug. Just 29 days.
On #298085... I usually give serious consideration to using core packages for a given purpose when I am setting up a server. For Ubuntu, that would be Postfix and Dovecot, rather than Postfix and Courier. It's nice to have all those 21,000 packages available for easy installation. But it doesn't mean you can expect platinum service when some package in Universe has a minor problem.
Posted Apr 30, 2009 5:28 UTC (Thu)
by muwlgr (guest, #35359)
[Link] (1 responses)
"You are trying to report a bug in the package outside of Ubuntu-main.
So please prefer the following way of actions :
1. Install a Debian-unstable version of this package on your system
This would teach me (and many others) to do the right things very soon.
Posted May 8, 2009 14:32 UTC (Fri)
by zenaan (guest, #3778)
[Link]
Posted Apr 30, 2009 5:39 UTC (Thu)
by muwlgr (guest, #35359)
[Link] (1 responses)
Re LP:352622, is there a minimal age limit for such bugs ? How long should the bug in 'main' stay unresolved to deserve an action from Ubuntu side ?
Posted Apr 30, 2009 23:02 UTC (Thu)
by Yasumoto (guest, #42642)
[Link]
The important thing to note about freezes is that they are there for a reason. If a fix/patch is "trivial" (which is a very vague term) then there should be no problems applying it. However, it is difficult to decide whether to introduce new code without giving it ample testing, since it may also include new bugs. I think it was Mark Shuttleworth that recently stated "The bug you know is better than the one you don't". There's a responsibility to the millions of users to not introduce breakage into their systems.
I know it takes a lot of work, and in an ideal world, bugs would magically get fixed, but that's not the case. If these issues are important to you, get on IRC or a mailing list and get some communication flowing.
Posted Jun 1, 2009 11:18 UTC (Mon)
by mdz@debian.org (guest, #14112)
[Link]
If you care about courier, and want to make sure that it's solid in each Ubuntu release, by all means dive in and help to maintain it. Otherwise, if you find that a version from Debian meets your needs better, you are welcome to use it instead.
Posted Apr 30, 2009 10:56 UTC (Thu)
by jldugger (guest, #57576)
[Link]
Courier is in universe, a best effort project to rebuild Debian packages not in Ubuntu main. If you strongly rely on packages in universe, you should be taking steps to either participate in MOTU or hire someone who does. Or you can simply use Debian, who reports having fixed BTS #513102.
I will add that none of these bugs have been "swept under the rug", marked wontfix or notabug.
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
One of your bugs is an universe bug, so it's completely on community's shoulders, and the community that actually maintains 90% of the packages is Debian (which also has enough of tens of thousands of open bugs).
This is why if I want a bug fixed in Ubuntu, I report it to Debian where I'm guaranteed to have a real person maintaining the package.
There is currently ca. 1000 open bugs per one paid developer, so they need the community effort to collect bugs, mark as significant and combine duplicates.
In the interests of not repeating myself about the "community effort", see my previous comment and the resulting thread.
One more aspect is that some packages in main are more watched than others.
I was going to say, "What about firmware packages?" but then I realised they're in restricted, not main, which explains why no-one cares to actually fix this copyright infringement.
Karmic Koala open for development
It's not always adressed, but at least it's not marked invalid!
Well, so far every time I reported a bug in gcc, a developer made sure to verify it within a few days, even if the fix took longer. Contrast with Ubuntu, where nothing happens for a year, and then it gets closed because there's information missing or something (without anyone asking for more information). Especially interesting was this bug in Speex (which I maintain), which was causing one of the tools to segfault on startup on amd64. The bug was reported before the 6.06 release, it was already fixed upstream in a later version, and someone even posted a (2-liner) patch. Well, it took about a year of me harassing the developers for them to patch it.
It's not always adressed, but at least it's not marked invalid!
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
my use pattern for Ubuntu is slightly different that 'Boot LiveCD on a system with empty disk, click Install, wait for the process to complete' (which seems the only pattern they actually test).
Karmic Koala open for development
All these bugs are dire.
"""
Karmic Koala open for development
Please correct me if I am anywhere wrong.
Karmic Koala open for development
Karmic Koala open for development
Ubuntu really does not have that much resources to handle your report quickly and efficiently enough.
(rebuild it from the source if needed);
2. If the bug persists, report it to Debian maintainers;
3. If you find it is fixed in Debian, please tell us."
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development
Karmic Koala open for development