Re: On cadence and collaboration
Steve McIntyre st...@einval.com wrote: Hi, A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. Exaggeration, -1. Excuse me, what? This is exactly what happened for this past freeze, so you can take that back, kthxbye. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Jesús M. Navarro jesus.nava...@undominio.net wrote: Hi, That's exactly my point. We suck at freezing. The problem is not we suck at freezing. Quite on the contrary I think I should have written we suck at operating during the freeze or something alike, that was a bit of a bad shorthand :) Debian developers, the release team, the debian-installer team... all of them have done a really *amazing* work in the past, and I can say this without being suspected being just a mere user myself. All things considered (size and nature of the project, nature of the contributions, governance model, ...) I think we're doing amazingly well. It could be a lot worse, especially given nobody has ever done that before. We're bigger than any other project, nobody has been there before us. In the early days of Debian, the lesser number of packages and archs made (barely) possible the monolithic freeze. When people where overhauled (I think I remember it by the slink-potato or maybe potato-woody days) new tools pushed forward the frontier (and due to this package and arch numbers skyrocketeed), then the woody-sarge days again exposed the problem. Back in the days, frozen was just that and unstable was carrying on with its life (with a bit less activity, but only a bit). Today, unstable is just as frozen as testing is during the freeze. In the end, testing kind of works to prepare a consistent set of packages that we can freeze at some point, so it's a good development tool, but it's not a good release tool. WRT unstable, testing is a step backward. A lot of things need to line up for a release. Debian is very large and the windows of opportunity are few and small. True. But that adds more value to the cartesian divide and conquer idea for problem approaching. This, of course, wouldn't be without its own share of If you're talking of freezing/releasing different sets of packages more or less independently etc, this has been discussed to death already. You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach It's not that difficult. It does happen, simply because since the testing introduction (and Ubuntu) we have less users using unstable and reporting bugs. The direct consequence is that bugs do make it to testing more than we'd like. Seriously, everybody gets bored and fed up during a freeze. Not because of the freeze itself but because it takes so long. Again, i.e. Both, actually. I am of the opinion that no matter how hard you try, you can't *make* a Debian release happen. I never thought about it that way but I think you marked the bull-eye. I think to remember something Schopenhauer said once about intuitions. And then, following Schopenhauer on this, although you cannot make it happen you still can make it easier for it to happen. My point exactly. You can *only* help the process. I understand just how frustrating that can be for release managers, but it's something that you need to accept to do this job. There's some point at which the release starts to happen, a point where a critical mass of DDs is reached, the point where everybody uses the word release more than any other word. All of which have some very real technical grounds and a heavy psycological Absolutely. nature too. Just the fact of being seriously comitted to a time-based release instead of current we aim towards this or that date that nobody takes really seriously but as a wishful grosstimate would heavily help for the critical DD mass and the going for the release attitude to happen. I think there's been a real push over the last years and a lot more DDs are focused on getting releases out the door now. We talk about releasing more than ever, so this cannot escape anyone nowadays. As for the cadence, the 18/24 months is something that looks like it can work repeatedly and is generally a good pace for us etc. So, in a nutshell, it's all there already, though not as formal as some would like it to be, it seems. developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). Remember dunc-tank? Yes, but I don't think it as a demonstration that money can't really help (or can just really help that much) but as a misguided and mistimed attempt doomed to fail. Fair enough. What we'd need is some sort of upstream academy where we could teach upstream: [...] Yes... It might be worth it some kind of best practices manual coupled with some kind of peer-review process for such practices (the equivalent to the I think something more interactive and hands on would be best. RTFM never worked that well in this case. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1
Re: On cadence and collaboration
On Wed, Aug 05, 2009 at 10:51:08PM -0500, Peter Samuelson wrote: [Pierre Habouzit] It yields a really costly entry point to target Linux as a platform, and it's exactly why most Software Vendors target RHEL and not Linux. And that's part of the reason[1] why most of our customers are using RHELs: software vendors only certify their stuff for RHEL, because it's the established reference in the field, and that it costs too much to certify you stuff for yet-another-distro. Ahhh, so you're trying to reinvent the LSB. You could have said so earlier, it would've saved some time. Actually not, I'm just explaining why I don't think that the Linux distributions diversity is an asset. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
the role of the LSB (was: On cadence and collaboration)
also sprach Pierre Habouzit madco...@madism.org [2009.08.05.2333 +0200]: But speaking from my experience as an employee of a software editor, I can tell that the distribution diversity is a huge problem when it comes to distributing our work. If your client use a Ubuntu LTS, a RHEL, a SuSE or worst for some, some kind of home-brewed monster taken half from a RHEL and custom packages (*sigh*) then you have as many builds to do, regress-test and so on. When you target Windows or Solaris or MacosX, you usually officially support the last two releases, and that's it (and please, it's the same for Linux distributions, for RH you have to support RH4.x and RH5.x if you want to be relevant). I think it's the job of something like the LSB to ensure a necessary baseline across distros on which vendors can build. Anyone gearing software at distro-specifics is committing the same fallacy as people writing HTML for Internet Exploder. And distros who are actively ignoring or superseeding the LSB are counter-productive. Vendors will always find reasons to limit themselves to one or two distros. IME in the past, that has not been because those distros are the only ones that can run their software, it's much more the case that their software engineers have no time to do the testing across all distros, and their support engineers don't know anything else and are thus unwilling to support it (warranty void). Synchronising software isn't going to change that — the distros will still be unique in their own ways. But let me put this into the proper relation: I think collaboration across distros is desirable (cf. vcs-pkg.org). I think it would be great if we got GNOME to agree on a long-term-support version, and dto. for Apache, gcc, all the others as it means time savings for everyone (less work duplication), and the possibility for more innovation. I just don't think it'll solve the vendors problem, nor eliminate all other problems relating to distro diversity. Heck, it might even create new problems, e.g. security issues as Julien suggested. Let's just stay real. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems verbing weirds language. -- calvin digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
Mark Shuttleworth schreef: I think most are waiting to see if Debian and Ubuntu can do this. If we can, I am very confident we will get a group of other distributions participating in the version harmonisation discussions in the first round. To win Novell we would have to actually demonstrate the process works, I think. And to win Red Hat we would need to demonstrate it works with everyone else first. At least, that's my impression from conversations to date. Redhat/Fedora seems to be difficult to win, but is a strong partner. Maybe we could try to make a freeze with both Debian and Ubuntu on a date that RedHat freezes in the hope Redhat likes it for a next time. We can do our best to make it attractive for them. Ubuntu will maybe be the first to release. No problem for me. Important point for me to choose Debian is the security-support on all packages. And Debian stable has more time so it can learn from problems in other distributions. With regards, Paul van der Vlis. -- http://www.vandervlis.nl/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the role of the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote: also sprach Pierre Habouzit madco...@madism.org [2009.08.05.2333 +0200]: But speaking from my experience as an employee of a software editor, I can tell that the distribution diversity is a huge problem when it comes to distributing our work. If your client use a Ubuntu LTS, a RHEL, a SuSE or worst for some, some kind of home-brewed monster taken half from a RHEL and custom packages (*sigh*) then you have as many builds to do, regress-test and so on. When you target Windows or Solaris or MacosX, you usually officially support the last two releases, and that's it (and please, it's the same for Linux distributions, for RH you have to support RH4.x and RH5.x if you want to be relevant). I think it's the job of something like the LSB to ensure a necessary baseline across distros on which vendors can build. Anyone gearing software at distro-specifics is committing the same fallacy as people writing HTML for Internet Exploder. And distros who are actively ignoring or superseeding the LSB are counter-productive. You're comparing apples and oranges here, for HTML is a standard, and theoretically, following the standard is enough (and even that is probably -- and sadly -- a fallacy). When it comes to the LSB, it doesn't say what happens when you're using very specific bits of the Linux kernel or the GNU libc, and when you're doing networking stuff for example, well, that matters a lot. That's why LSB doesn't work for many vendors because of the very different toolchains. You have to do regression tests for every single distro out there, which many corporations cannot do, hence certify only for a couple of distributions (and often only one: RHEL). Anyways we're drifting away from the original point, so just let cut that here. I just don't think it'll solve the vendors problem, nor eliminate all other problems relating to distro diversity. Heck, it might even create new problems, e.g. security issues as Julien suggested. That's beside the point, if anyone thought I was saying that aiming to synchronized freeze would solve the vendor problem, then I've probably been ambiguous. I've never meant it. I was merely explaining why the Distribution diversity is, in my opinion, not something that one can call an _asset_. It's a variable that you have to live with in the free software world. It has its upside and its downsides, but it's neither an asset nor a defect. I'm really sorry if I let people think that I'm advocating synced freezes so that LSB can be done right. It had never even crossed my mind. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On 2009-08-06, Josselin Mouette j...@debian.org wrote: And this is precisely why it was asked that for squeeze, frozen and testing remain different suites during the freeze. Currently I have no idea of whether this will happen. While I see the point of this I don't know if I would be happy. If people just continue with business as usual for unstable and testing we will not release. See the RC bug fixing activity of the last release. A short freeze just means that people would actually have to squash some bugs, but it seems that the majority of DDs simply don't care. Freezing a bit of unstable helps us to apply some peer pressure. Kudos to all of them who helped releasing in the last freezing cycle. I just don't like the perspective of feeling alone in the next one. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the role of the LSB (was: On cadence and collaboration)
also sprach Pierre Habouzit madco...@madism.org [2009.08.06.1104 +0200]: You're comparing apples and oranges here, for HTML is a standard, and theoretically, following the standard is enough (and even that is probably -- and sadly -- a fallacy). LSB is growing to be just that, but it won't stand a chance if people/distros don't work with it. When it comes to the LSB, it doesn't say what happens when you're using very specific bits of the Linux kernel or the GNU libc, and when you're doing networking stuff for example, well, that matters a lot. That's why LSB doesn't work for many vendors because of the very different toolchains. I am failing to accept that vendors need to use those very specific things in their software, just like I doubt that people need IE-HTML to make their sites render properly. I think laziness^W business thinking is more likely an option. Anyway, if there is something that should be standardised, well, bring it up to the LSB. The W3C and web-standards groups didn't suggest to synchronise the rendering engines between all browsers. They defined standards. I think that's what we ought to do too. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems this sentence contradicts itself -- no actually it doesn't. -- douglas hofstadter digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. Cheers Luk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Luk Claes l...@debian.org (06/08/2009): If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. We already have maintainers working against any kind of common sense. We have maintainers breaking transitions, delaying them, or starting them when they're not welcome. We even have a mechanism to enforce sanity (transition-related upload prevention/blocks). Why would/should the freeze be treated in a different manner? Mraw, Mooty KiBi. signature.asc Description: Digital signature
Re: Opera in your repos
On Wed, Aug 05, 2009 at 11:44:00PM +0200, Ilya Shpan'kov wrote: I will inform our lawers about your opinion. Really, it have a very big sense. I can say, that here in Opera we had discussions about being Free Software every year. Unfortunately, we have a lot of agreements with other companies which use Opera at their devices - by this case we still can't to be a real free Software. If you mean you are using 3rd party code which is licensed to you under proprietary terms - there is not much you can do I guess. If you mean you and your partners rely on commercial exploitation of (some of) the features of Opera - there is always the possibility of dual-licensing the code to GPL/Proprietary together with forced copyright assignments (so Opera retains control of the general direction and can relicense/exploit the code). This way, no other company can exploit the code in a proprietary way (or has to disclose their modifications) while Opera still can (as the code owner through the alternative proprietary license). Whether you attract a lot of outside developers this way (due to truely free alternatives like Webkit and Gecko) is a different matter, of course. regards, Michael -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the role of the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 02:02:59PM +0200, martin f krafft wrote: also sprach Pierre Habouzit madco...@madism.org [2009.08.06.1104 +0200]: You're comparing apples and oranges here, for HTML is a standard, and theoretically, following the standard is enough (and even that is probably -- and sadly -- a fallacy). LSB is growing to be just that, but it won't stand a chance if people/distros don't work with it. When it comes to the LSB, it doesn't say what happens when you're using very specific bits of the Linux kernel or the GNU libc, and when you're doing networking stuff for example, well, that matters a lot. That's why LSB doesn't work for many vendors because of the very different toolchains. I am failing to accept that vendors need to use those very specific things in their software. just like I doubt that people need IE-HTML to make their sites render properly. I think laziness^W business thinking is more likely an option. Probably because you don't write this kind of software then. I'm working for telco stuff, we have very specific needs towards the high availability interfaces (epoll and similar) linux provides, and its SCTP stack. This only has caused us major issues in the past. Then you add the fact that binary compatibility is a joke (openssl has not the same soname on RH and Debian e.g.). And on top of that you add binutils so crappy that our software misbuilds on those platforms. Sorry but no, you cannot make abstraction of that, on this, _you_ are not living in the reality. FWIW I would dream for my work that I could count on decently similar kernels, toolchains and libcs on all distros. Only that would be cause for joy and happiness here. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: the role of the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 02:49:37PM +0200, Pierre Habouzit wrote: On Thu, Aug 06, 2009 at 02:02:59PM +0200, martin f krafft wrote: I am failing to accept that vendors need to use those very specific things in their software. just like I doubt that people need IE-HTML to make their sites render properly. I think laziness^W business thinking is more likely an option. Probably because you don't write this kind of software then. I'm working for telco stuff, we have very specific needs towards the high availability interfaces (epoll and similar) linux provides, and its SCTP stack. This only has caused us major issues in the past. For that sort of stuff you normally end up needing to validate the binary image of the system anyway - especially if the telco thinks it can get away with charging you for compliance testing on any change. What coding to standards buys you is a greater degree of protection against things breaking underneath you which does get you 90% of the way there. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the role of the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 08:52:10AM +0200, martin f krafft wrote: I think it's the job of something like the LSB to ensure a necessary baseline across distros on which vendors can build. Well, maybe; however the LSB is *very* baseline, so not very useful. Besides, it is heavily geared towards ISVs, not other FLOSS projects. Having a unified set of core packages across a number of important distributions would make it easier for other upstream projects to target their support at (as opposed to just supported the latest stable or even unstable/snapshot release). And in the end, the LSB would profit as well, as it could more easily define the set of base packages required, based on what is decided upon by the those interacting distributions. Whether this is something Debian should desire is a different matter I have not made up my mind upon. Michael -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:21:49PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (06/08/2009): If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. We already have maintainers working against any kind of common sense. We have maintainers breaking transitions, delaying them, or starting them when they're not welcome. We even have a mechanism to enforce sanity (transition-related upload prevention/blocks). Why would/should the freeze be treated in a different manner? There have always been, and always will be, a small subset of developers who work against our freezes out of ignorance or even hostility. For the most part, however, developers seem to be pretty good at acting in their own enlightened self-interest, and not behave in ways that are guaranteed to make the freeze longer by making it harder to release. It's hard to measure this quantitatively because you don't have a real control, but certainly my subjective experience is that this is very effective. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote:
Or is some incremental freeze still supposed to happen?
During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.
Note, however, that we have always used to have unblocks during
freezes; the policy on how unblocks are handled is completely
orthogonal to how sharply you freeze.
(Putting -release in Cc to catch their attention.)
Keeping that to ensure I'm not on crack with my memories :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote:
During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.
^
Here of course I meant freezing.
.oO( is that an instance of a freudian typo ?)
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: On cadence and collaboration
[Please Cc: replies back to me, I'm not on debian-proj...@] Mark, I think you have a biassed view in your role as Ubuntu maintainer. This isn't bad in itself, but it needs to be written so that positions are clear. My position is: I'm currently using openSUSE for my development, with occasional portability tests on Solaris, NetBSD, FreeBSD, Ubuntu. I'm looking after my Mom's Ubuntu installation. More importantly, I'm also an upstream maintainer of fetchmail and leafnode, and I'm also co-maintainer of bogofilter. I would not consider any of these projects large. This is not Mozilla, Adobe. Still, my upstream maintenance considers needs of users and distributors, i. e. I will usually accept bug reports for outdated versions if I know that area of the code hasn't changed. The whole longish message of yours is about telling that others need to move and how good it all could be if everbody did, and you're pulling an argument that this was in the interest of end users. This is but a pretext, Ubuntu apparently doesn't catch enough karma among developers through deeds and achievements, and your begging for compromises isn't bound to improve on that, but quite the contrary. There are some key points of criticism I'd like to mention: 1. General communication with upstream maintainers, and consequences I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for packages I (co-)maintain upstream. Upstream here is at the origin, not Debian packaging or something, list as above. Some were relevant and still current, and Ubuntu failed to either do something about the bugs (as in debug, write a patch) or at least tell people who were in a position to do something about the problem, concretely, forward the bug upstream. This is the very least you must do. Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829 This had sufficient information to debug, and lay around for half a year. Nobody in Ubuntu bothered to look at the report, or to forward it to the upstreams. Another observation is that Ubuntu bugs and bug changes are frequently forwarded to dozens of people, yet nobody cares to look. All you get is me too or dramatic narrations of how the bug ate somebody's dog. From maintainers, such as ubuntu core maintainers, for core packages: deafening silence. I'm happy to help distributions (without picking any particular, I don't care about your name, but about how you act), but I'm definitely not going to ferret up the downstream maintainers or their bugs. This was a one-time event. Some proposals for Ubuntu's part in this: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. iii. if you take my work (i. e. upstream tarball), and you're a downstream packager, it's your moral duty to approach me and tell me who you are and what you do. We appear to share the intention of improving user experience, but as written earlier, I'm not going to ferret up all possible downstreams. And there is prior evidence that my expectations work out: I have occasional contact with the downstream maintainers of other distributions, such as FreeBSD, NetBSD/pkgsrc, Debian, Fedora/Red Hat, OpenBSD, openSUSE. Often, new-coming packagers will approach the upstreams and introduce themselves, and perhaps share questions, bug reports or patches. I've never seen this happen for Ubuntu. Bottom line: Ubuntu has to work about something, or to contact whoever they feel fit, if they want something to change. 2. Getting innovations right, and going them all the way Ubuntu has some interesting approaches, such as Upstart. However, these are incomplete, underdocumented, and in consequence half-baked. If you care about the end user experience, you've got to bite the bullet and not only lick it. Discussing about superimposing schedules and conferences doesn't help at all. Providing half-baked solutions is a real nuisance for the end user and the upstreams: it creates the very inconsistencies that you'd like to avoid, and it adds one more item to the half-baked items list. Users get deprived of the old way of doing things (or it's a whole heap more work to do it the old way), the new way doesn't work yet, and upstreams sometimes see the fallout of such downstream changes. Across all Linux distributions, the most prominent innovations I recall are, in random order: X, X-autoconfig, Intel driver for X, dbus/HAL, NetworkManager, Pulseaudio, Upstart, KDE4 (and particularly the lack of established and crucial features therein, such as X.509 certificate management). You can't expect other distributions to collaborate if you don't muster the
Re: On cadence and collaboration
On Wed, 05 Aug 2009 10:21:38 +0100 Mark Shuttleworth m...@ubuntu.com wrote: Hi folks Hi there We're already seeing a growing trend towards cadence in free software, which I think is a wonderful move. Here, we are talking about elevating that to something that the world has never seen in proprietary software (and never will) - an entire industry collaborating. Collaboration is the primary tool we have in our battle with proprietary software, we should take the opportunities that present themselves to make that collaboration easier and more effective. Truly an enthusiastic speech which gives us a vision of a bright new world and even includes the yes we can spirit. And yet I lack the trust that such will ever happen. To convince so many and so diverse groups to all commit to a single goal, and may it just be something as profane as a common freeze date, would be unprecedented in human history. But let's assume I'm wrong, and it is actually going to happen ... Well, the first thing is to agree on the idea of a predictable cadence. Although the big threads on this list are a little heartbreaking for me to watch, I'm glad that there hasn't been a lot of upset at the idea of a cadence in Debian so much as *which* cadence. We can solve the latter, we couldn't solve the former. So I'm happy at least at that :-) I'm sorry then to rain on your parade. Despite the risk of being accused of heresy, let me state my doubts about such a move in general. I leave discussions about specific advantages or disadvantages that this might hold for Debian to others, much more competent on the matter. Instead I would like to approach this issue more abstractly. We know of many examples in nature, human society, economics, computing, etc., that show that distributed, non-hierarchical, self-organising system can be much more powerful than centrally controlled systems. It can be proved, for instance, that a swarm of independent units without central control can converge a solution in cases, where classical iterative schemes that have such a central control do not[0]. Add central control (a central clock) and this power vanishes. While it is not clear if such a model applies to the FLOSS world without doing extensive research, I strongly believe that it would harm the system if you add a central control (in this case some central committee that decides on freeze dates). While it might look appealing at first sight to have a central authority to decide on certain matters, this rips the system of the ability to change quickly and adapt to new circumstances. But let's again assume that I'm wrong and that it would do the FLOSS world good. But: good how? What exactly will be better? It is an ambitious goal you propose which will require projects to make compromises, to invest time and possibly money, to change their priorities. So at the end of the day people will want to know if it was worth the investment. What are the criteria on which this question can be decided? That, say, GNOME releases in time for the distributions to pick it up is easily testable, but not an advantage on its own. That the world becomes a better place is a worthwhile goal but impossible to verify. Would you please give verifiable and falsifiable criteria which can be evaluated objectively to answer such a question? Examples would be - the productive work/bug fixing ration increases - less security leaks - number of people moving to GNU/Linux per year increase - etc. At the moment it is not clear for me, what the real advantage for projects and users would be. However, I completely agree that collaboration helps everybody. But instead of inserting an additional level in the hierarchy to govern such collaborations, I believe the better approach is to tighten the collaboration-network. Here collaboration happens on a different level. Between package maintainers and their upstream, between projects that depend on each other, between Debian package maintainers and Ubuntu package maintainers, etc. Cheers, harry [0] Gerardo Beni: Order by Disordered Action in Swarms. signature.asc Description: PGP signature
Come join me on ThaiMLMcenter.com
ThaiMLMcenter.com: Come join me on ThaiMLMcenter.com! Visiorichteam Thailand Click the link below to Join: http://thaimlmcenter.ning.com/?xgi=1rvN9Xr If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on ThaiMLMcenter.com witchawat, Narongsak, natharn na bangchang, Rachain Jantaboon, wichein jaita About ThaiMLMcenter.com ยินดีต้อนรับสู่ ThaiMLMcenter.com ศูนย์รวมความรู้ ข่าวสาร และแหล่งข้อมูล ของธุรกิจออนไลน์ และเป็น เครือข่ายสังคม ของนักธุรกิจออนไลน์ 326 members 41 videos 16 discussions 38 blog posts To control which emails you receive on the corner, or to opt-out, go to: http://thaimlmcenter.ning.com/?xgo=Z0tROduFN90xhGsVHJ5Uxn19QhNWcEvt1m/MpRsV6K0FsyjavK2TTcMTHnI6MZPEbcjMS7bD6rk
Re: On cadence and collaboration
On Wed, Aug 5, 2009 at 4:44 PM, Mark Shuttleworthm...@ubuntu.com wrote: The proposal as I understood it was that in December, the key component maintainers / release managers from all interested distributions would discuss, on a public mailing list, their plans for the base versions of those components in their 2010 releases. Well, this is not the proposal as it was announced, and this is definitely not what we understand as freeze in Debian. In Debian, freezing in December means that no new versions enter testing after the freeze begins. I think the proposal as you word it would be fine, since this would probably mean freezing later on. Maybe March or so. This would make much more sense, from my point of view. But this is NOT what was announced and communicated to us. The rough guide I heard was that, if we looked at the list in December, we'd probably be able to agree on things like the default versions of Python, Perl, X and GCC, but that it might be harder on kernel, GNOME and KDE. That's OK by me - whatever consensus *does* emerge from the process is a win that we otherwise would not have. Some teams may not be ready for the discussion, some might be. That's OK too. I don't think it makes sense to rush our release as much as it's being proposed only to finish with different versions of big components. I understand that GCC and X are important, but I don't think all the hard work makes sense unless we can also sync the desktops. The difference in our language is about the meaning of freeze in December. I think December is not about actually freezing, it's about reviewing and planning and looking for opportunities. Certainly, I think the Debian team will want to freeze some things very early (December!), but some maintainer teams may well be willing to commit to using something that will freeze a little later, especially if they can collaborate well with Ubuntu on those packages. That's not how it has worked in the past. We've had some scaled freeze, freezing the toolchain first and the rest of the packages afterwards, but it's never been some maintainer teams who decided what was frozen and what wasn't, it's always been the Release Team. And the Release Team has said that they'd rather not do the scaled freeze this time, they'd rather just do one freeze, and get it over fast. I think that there is a significant difference on how Debian and Ubuntu work towards a release which means that speaking about a December freeze has very different consequences on each distribution. So, maybe we need to change the terms, so that we are both speaking about the same thing. It's true that Decembers a fractured month, and it would arguably be better to do heavy lifting in another month. I imagine the main work will really be Feb-March, once the decisions are final and widely communicated. Again, this was not what was announced, it's not what we were expecting after the We freeze in December plan. I personally wouldn't object to a general let's decide what we want in our distro discussion in December, as long as the freeze is done after those components have been included. That means that if we want March's GNOME, we would have to freeze in April. If we (as in Debian) freeze in December, then there's absolutely nothing to discuss. We already know what we are going to ship. Finally, the whole idea of the time based freezes was to know when we were going to freeze, so that maintainers could work towards that. If the freeze date is decided in the December discussions, then we are back to the current (or past) model, of freezing at some unknown point. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: GRUB 2 is going to be another opportunity where Ubuntu can prove either useful or detrimental to your stated goals: invest time to polish it and contribute back to the upstream; or use it raw as it is and leave the user with the shards if it breaks. The upstream abandoned GRUB 1, GRUB 2 isn't ready. This is a good point where people can actually help: GRUB 2 is, besides all other shortcomings, severely underdocumented. Ubuntu as a very user-friendly distribution probably has skilled writers at hand - task some of them to produce useable documentation on GRUB 2. The rest of the mail which I am replying to gets a clear +1. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Am Donnerstag, den 06.08.2009, 18:01 +0200 schrieb Marc Haber: On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: GRUB 2 is going to be another opportunity where Ubuntu can prove either useful or detrimental to your stated goals: invest time to polish it and contribute back to the upstream; or use it raw as it is and leave the user with the shards if it breaks. The upstream abandoned GRUB 1, GRUB 2 isn't ready. This is a good point where people can actually help: GRUB 2 is, besides all other shortcomings, severely underdocumented. Ubuntu as a very user-friendly distribution probably has skilled writers at hand - task some of them to produce useable documentation on GRUB 2. But please note that if you want to help with an official GRUB 2 manual, then everyone needs to assign copyright to FSF. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Philipp Kern tr...@philkern.de writes: On 2009-08-06, Josselin Mouette j...@debian.org wrote: And this is precisely why it was asked that for squeeze, frozen and testing remain different suites during the freeze. Currently I have no idea of whether this will happen. While I see the point of this I don't know if I would be happy. If people just continue with business as usual for unstable and testing we will not release. See the RC bug fixing activity of the last release. A short freeze just means that people would actually have to squash some bugs, but it seems that the majority of DDs simply don't care. Freezing a bit of unstable helps us to apply some peer pressure. Kudos to all of them who helped releasing in the last freezing cycle. I just don't like the perspective of feeling alone in the next one. Those who haven't seen it already might want to watch Theo de Raadt's presentation this year on how OpenBSD releases. It seems directly relevant and very similar to our current release process, except they manage more consistent timing (in large part, I think, because the amount of software they're freezing is smaller and they have more control over it). http://www.youtube.com/watch?v=i7pkyDUX5uM -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote: On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote: Or is some incremental freeze still supposed to happen? During the talk/discussion at DebConf, IIRC Luk stated that incremental freezes had a negative effect because for many developers it was not clear what/when was going to be frozen. The logical consequence drawn there (again, IIRC) has been that the release team would prefer freezing all at once. Note, however, that we have always used to have unblocks during freezes; the policy on how unblocks are handled is completely orthogonal to how sharply you freeze. (Putting -release in Cc to catch their attention.) Keeping that to ensure I'm not on crack with my memories :-) You're not, it's IMHO a faithful wording of our position (with the s/releasing/freezing/ fix ;p) -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Julien BLACHE wrote: Discussing the validity of security policies is not the point of this thread, so let's leave it at that, please. It is exactly the point of this thread if you use it as an argument against a common freeze cycle. This was only an example, there are others, nitpicking on this one (or any other, for that matter) is pointless. It's OK to bring it up as an argument, but not to counter it? Counter-argument != nitpicking. I wholeheartedly agree there are other examples, pro and con, but since you brought this up as an argument, there's nothing pointless in countering it. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
upstart and the LSB (was: On cadence and collaboration)
also sprach Matthias Andree matthias.and...@gmx.de [2009.08.06.1625 +0200]: Ubuntu has some interesting approaches, such as Upstart. However, these are incomplete, underdocumented, and in consequence half-baked. If you care about the end user experience, you've got to bite the bullet and not only lick it. Discussing about superimposing schedules and conferences doesn't help at all. Providing half-baked solutions is a real nuisance for the end user and the upstreams: it creates the very inconsistencies that you'd like to avoid, and it adds one more item to the half-baked items list. Users get deprived of the old way of doing things (or it's a whole heap more work to do it the old way), the new way doesn't work yet, and upstreams sometimes see the fallout of such downstream changes. … and all of the efforts of the LSB to standardise sysvinit so that every vendor can drop init.d scripts into place and expect them to work, are undermined by upstart. Sure, it has compatibility addons, but primarily it conflicts with sysvinit and encourages vendors to provide upstart control files for packages, instead of init.d scripts. I can make Check Point Firewall-1, which is said to only work on RedHat -2 work on Debian in a jiffy. I will not replace sysvinit or /sbin/init on crucial systems with something that hasn't been around enough long enough for people to understand and embrace with all their heart. Don't get me wrong: I long for upstart's functionality. It just seems half-baked and counter-productive when viewed in the light of the LSB efforts. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems anyone who says sunshine brings happiness has never danced in the rain. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
When I look over the commentary on debian-devel and in debbugs and on #debian-devel, I see a lot of familiar names from Ubuntu, especially on the deep, hard problems that need solving at the core. I'm proud of that. There is unnecessary incompatibility between Ubuntu and Debian. Their incompatible bts is one that personally bits me. The Ultimate Debian Database helps show ubuntu/debian package relationships. http://udd.debian.org/ http://wiki.debian.org/UltimateDebianDatabase Unfortunately Debian and Ubuntu use incompatible bts systems. Currently Ubuntu's launchpad based bug tracking system _bts_ is lacking accessible package version information. Bug tracking information tied to package version is essential for debian where packages go through many version iterations between releases. Package bugs should not be tracked based on the release. They must be tracked based on their version. This was part of the original design for Launchpad Bugs, but it never came to fruition. The very earliest bug still open on Launchpad Bugs asks for this: https://bugs.launchpad.net/malone/+bug/424 Up to and including Hardy, ubuntu used apt-listbugs which referred to debian's bts with package version tracking. Even though this pulled bug information from the debian bts, it gave a reasonable indication of what packages contained significant bugs. apt-listbugs was withdrawn, because ubuntu package customization increasing has made the related debian bts irrelevant. Topic branches and topic trees of are ways by which package customization can be tracked. In order to meet the Debian Collaboration Team's objective the launchpad bts must interface with the debian bts. Only this way developers benefit from the topic branches, trees of distributed package source control. To collaborate bugs must be tracked across both debian and ubuntu and be accessible to both native debian and ubuntu developers.
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: [Please Cc: replies back to me, I'm not on debian-proj...@] FWIW, this is an excellent mail, and I share many of your opinions and hindsights here. Note that by your count Debian isn't always a good player with upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS on your packages too ;) -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: upstart and the LSB (was: On cadence and collaboration)
On Thu, Aug 06, 2009 at 08:50:36PM +0200, martin f krafft wrote: … and all of the efforts of the LSB to standardise sysvinit so that every vendor can drop init.d scripts into place and expect them to work, are undermined by upstart. Right, just like the efforts of the LSB to standardize a package format are undermined by our use of .deb. Sure, it has compatibility addons, but primarily it conflicts with sysvinit and encourages vendors to provide upstart control files for packages, instead of init.d scripts. Why in the world does it matter whether it's a compat layer, or if it's what the distributor uses for its own work? Do you advocate throwing away Policy and replacing it with the LSB? I will not replace sysvinit or /sbin/init on crucial systems with something that hasn't been around enough long enough for people to understand and embrace with all their heart. Don't get me wrong: I long for upstart's functionality. It just seems half-baked and counter-productive when viewed in the light of the LSB efforts. Not in the least. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On 2009-08-06 16:25:47 +0200, Matthias Andree wrote: [I'm Ubuntu developer (MOTU to be more specific), so I might be biased] I certainly won't excuse some things that are not happening, I know that Ubuntu needs to improve in some aspects. But realising this and get things improved are still not the same. I just want to add some data which hopefully explains why things are happening or not happening. 1. General communication with upstream maintainers, and consequences I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for packages I (co-)maintain upstream. Upstream here is at the origin, not Debian packaging or something, list as above. Some were relevant and still current, and Ubuntu failed to either do something about the bugs (as in debug, write a patch) or at least tell people who were in a position to do something about the problem, concretely, forward the bug upstream. This is the very least you must do. Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829 This had sufficient information to debug, and lay around for half a year. Nobody in Ubuntu bothered to look at the report, or to forward it to the upstreams. I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). Another observation is that Ubuntu bugs and bug changes are frequently forwarded to dozens of people, yet nobody cares to look. All you get is me too or dramatic narrations of how the bug ate somebody's dog. From maintainers, such as ubuntu core maintainers, for core packages: deafening silence. When you mean the Also notified list: this list includes people subscribed to bugmail for a package (none are subscribed for bogofilter) and people subscribed to all bugmail. I don't know why so many people subscribe to all bugmail as I certainly couldn't handle that volume. I'm happy to help distributions (without picking any particular, I don't care about your name, but about how you act), but I'm definitely not going to ferret up the downstream maintainers or their bugs. This was a one-time event. Some proposals for Ubuntu's part in this: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. I know :( I was about to nearly stop filing bugs myself for this reason (no one commented) before I got involved into Ubuntu and realized myself that there is simply not enough manpower for everything. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. Unlike Debian, Ubuntu hasn't this one maintainer per package approach (don't know about other distributions). In Ubuntu whole teams are responsible for the components: core-dev for packages in main and MOTU for packages in universe and multiverse. Both approaches have there pro and con. For and a package being in main doesn't necessarily mean that it's better maintained than packages in universe (on a best effort basis). They might only be in main because they are needed by an other package in main (sorry, don't know the reason for bogofilter being in main). While Debian has over 1000 persons with upload rights, Ubuntu counts only 135 persons with upload rights (from those only 56 can upload to main). At the same time there are over 3000 source packages in main and over 12000 source packages in universe. One can easily see that this won't work to get every package the amount of care that it deserves. So in the end many packages are taken unchanged from Debian. Yet bugs don't stop getting filed in Ubuntu and need to be looked at and acted accordingly. Michael -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Michael Bienia mich...@bienia.de writes: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). You know those long, heated arguments that Debian has had in the past about web-based bug-tracking systems, reports from users who don't know how to report bugs, how getting a large quantity of bugs isn't necessarily useful compared to getting high-quality bugs, and how making it too easy to report bugs can just result in the bug tracking system being flooded with bugs that no one ever looks at? Yeah, that. Certainly, my experience is that for many of the packages that I maintain in Debian which are also in Ubuntu, the only person who ever looks at the Ubuntu bugs and does anything about them is me. Which is ironic, given that I don't use Ubuntu and can't test directly any of the problems that people report. The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Am 06.08.2009, 22:22 Uhr, schrieb Pierre Habouzit madco...@madism.org: On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: [Please Cc: replies back to me, I'm not on debian-proj...@] FWIW, this is an excellent mail, and I share many of your opinions and hindsights here. Note that by your count Debian isn't always a good player with upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS on your packages too ;) Definitely, but I consider myself lucky that the current Debian packagers of my upstream projects are quite good at taking the relevant issues upstream and being responsive and helpful if needed, so at least I'm/we're aware upstream and can see if issues are reported from one end user as a random finding, or if constant streams of reports come from various places. Rotting bugs? Indeed there are some. In doubt, I prefer keeping stable versions going over abandoning them for a development version that is going to be finished many a year in the future. It's annoying to see this if I could overhaul subsystem X and Y, I could finally fix bug 12345 while receiving bug reports or browsing the trackers, but it avoids the far bigger annoyance of letting an old stable version rot and not having a new devel version stable yet -- that would be a real PITN for both end users and downstream distros. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On 2009-08-06, Russ Allbery r...@debian.org wrote: The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. While the upgrade errors are mildly annoying (somebody *did* expirience them, though), the automated coredump retracing is very, very useful. If anybody hits a segv in my C++ packages and go through the bug reporting process it's obvious what the problem is almost every time. But I guess we'll get there as soon as we have debug packages in place. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Philipp Kern tr...@philkern.de writes: On 2009-08-06, Russ Allbery r...@debian.org wrote: The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. While the upgrade errors are mildly annoying (somebody *did* expirience them, though), the automated coredump retracing is very, very useful. If anybody hits a segv in my C++ packages and go through the bug reporting process it's obvious what the problem is almost every time. But I guess we'll get there as soon as we have debug packages in place. Yeah, the ones that I was thinking of were the dpkg traces. Automated coredump backtraces would be awesome. The dpkg traces were much less useful. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
