Bug#684128: failure to communicate
On 4 April 2013 20:47, ian_br...@fastmail.net wrote: On Thu, 4 Apr 2013 19:09:04 +0200 Christian PERRIER bubu...@debian.org wrote: This mail is a very good argument to confirm that overcomplicated methods to make your point will just fail. If you have a point to make it, make ti. Once. With facts. I supplied plenty of facts. I was not following this bug report but reading it, it reminds me of the Unit Policy [1] that got approved and is gradually implemented in ubuntu/debian packages. Looking at d-i the usage is mostly correct sans 'k' should only be used lower-cased with current base-10 units. The major problem with changing these is that same prefixes are accepted for pre-seeding and it would be ill-advised to change those, thus backwards compatability must be preserved in the values that can be preseeded as well as entered by the user. The default to base-10 units, is good as majority of the installer deals with HDD drives (not SSD) and not RAM. If I have 1TB drive and want half of it for one thing and 1/4 for this and 1/4 for that, no space should be left on the drive. Hence matching and using same units as disk-manufacturers is good. The case where we mix match = e.g. making swap big enough (base-10) for RAM size (base-2) is tricky. And it's something to consider in the UI. I understand your frustration, but as it happens installer work/improvements becomes a hot topic post-freeze as this is when people start to use the installer, notice things and try to write features. And all of these features will only land for the next cycle with a release in ~= 2 years time. Tell me about bad timing, eh?! =) W.r.t. boundry alignments, I believe it its already aligning at 2048 by default and there is ongoing work to align with 4K boundries properly. But note that boundry alignment has little to do with user displaying/specifying amount of gigaheaps one wants to be allocated where. Everyone seems to agree to bring support to input/output Ki/Mi etc prefixes. That's a feature and can only go into jessie branches and or wait for wheezy release. Once that lands we can bike shed to death where to display what units and what to default to where going forward. [1] https://wiki.ubuntu.com/UnitsPolicy Regards, Dmitrijs. ps. there are disk manufactures that mix base-2 and base-10 units. E.g. using one to calculate 1MB and then using the other multiply and gain GB/TB factors /o\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684128: failure to communicate
On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote: The default to base-10 units, is good as majority of the installer deals with HDD drives (not SSD) and not RAM. Come on... it's not! Let's be serious 5 minutes here. There isn't even a warning about which units are in use. This fools our users (me included, for many years...). The freeze of Wheezy might be an argument, but what you wrote above, really isn't one. On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote: And all of these features will only land for the next cycle with a release in ~= 2 years time. I really hope that it wont be the case. That it doesn't go into Debian 7.0.0, I would understand, but at least, we need it for a point release. And at least, we need things written in the release notes about it, if not a message in the installer itself (Christian, don't kill me... ;). Could we stop the winning and have this bug fixed please, or the patch rejected (with a valid motivation)? Thomas P.S: Not only with SSD you have problems with boundaries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684128: failure to communicate
Hi Thomas, Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit : On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote: And all of these features will only land for the next cycle with a release in ~= 2 years time. I really hope that it wont be the case. That it doesn't go into Debian 7.0.0, I would understand, but at least, we need it for a point release. Are you seriously arguing in favour of pushing a behavioural change into a stable point release? I doubt the stable release team would accept that, but I'm not under their hats. And at least, we need things written in the release notes about it, if not a message in the installer itself (Christian, don't kill me... ;). I disagree. It has worked that way for a long time (and many releases in that timeframe), so it is probably not that broken. I'm not saying the bug isn't valid of course, just that it's severity is IMHO correct. Could we stop the winning and have this bug fixed please, or the patch rejected (with a valid motivation)? Could we stop the useless bikeshedding and have Wheezy released please? The patch doesn't need rejection: it is a valid patch for a valid bug. It just affects d-i, which is quite an important piece of software for sane Debian releases. As you know, d-i is critically low on manpower. You want that bug fixed? Great: test the patch, document your tests, upload to experimental with the patch, gather feedback, get involved, etc. For a fix to land in Wheezy, this should have happened 8 months ago. Now is the time to release Wheezy, not the time to add cosmetic and disruptive fixes to it. (And again, I think the changes are probably worthwhile, it's only the timing which is wrong.) OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684128: failure to communicate
On 04/06/2013 12:16 AM, Didier 'OdyX' Raboud wrote: Hi Thomas, Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit : On 04/05/2013 07:59 PM, Dmitrijs Ledkovs wrote: And all of these features will only land for the next cycle with a release in ~= 2 years time. I really hope that it wont be the case. That it doesn't go into Debian 7.0.0, I would understand, but at least, we need it for a point release. Are you seriously arguing in favour of pushing a behavioural change into a stable point release? I doubt the stable release team would accept that, but I'm not under their hats. I've wrote that we should at least address the issue, in a way or another, through the next point release if that is safer. But, are you seriously proposing that we leave the issue as-is ??? And at least, we need things written in the release notes about it, if not a message in the installer itself (Christian, don't kill me... ;). I disagree. It has worked that way for a long time (and many releases in that timeframe), so it is probably not that broken. Well, at least *I* didn't know it was broken (yes, you read well: BROKEN !!!), and I was quite shocked to read it, Knowing that absolutely nothing gives you clues about it is equally shocking. In fact, I saw that strange behaviors, and couldn't explain it. We are talking about someone who has been using Debian for 10 years. Now, think about someone who is a new comer... I'm not saying the bug isn't valid of course, just that it's severity is IMHO correct. Could we stop the winning and have this bug fixed please, or the patch rejected (with a valid motivation)? Could we stop the useless bikeshedding and have Wheezy released please? Sure. And let's add the fix for the next point release if everyone think it's not a good idea to fix it right now (though it's quite a shame we can't). That's all I'm saying. As you know, d-i is critically low on manpower. Yes, I know. And the patch author is also right to tell that refusing contribution isn't a good idea to address this lack of manpower. As much as I don't agree with his tone, I do agree with the arguments. You want that bug fixed? Great: test the patch, document your tests, upload to experimental with the patch, gather feedback, get involved, etc. For a fix to land in Wheezy, this should have happened 8 months ago. Do you believe the legend that d-i was frozen 8 months ago? I don't... :D (only half joking here...) Now is the time to release Wheezy, not the time to add cosmetic and disruptive fixes to it. I don't agree it is cosmetic. I'm not sure it's disruptive. (And again, I think the changes are probably worthwhile, it's only the timing which is wrong.) Then make your case for the next point release, not for Jessie, please ! Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684128: failure to communicate
[ Not answering all occurrences, things got repeated a few times… ] Thomas Goirand z...@debian.org (06/04/2013): I've wrote that we should at least address the issue, in a way or another, through the next point release if that is safer. It is not. But, are you seriously proposing that we leave the issue as-is ??? For wheezy, certainly. Sure. And let's add the fix for the next point release if everyone think it's not a good idea to fix it right now (though it's quite a shame we can't). That's all I'm saying. Now is not the time, point releases are not the time. Next release cycle is perfect for considering such requests. Now is the time to release Wheezy, not the time to add cosmetic and disruptive fixes to it. I don't agree it is cosmetic. I'm not sure it's disruptive. It is disruptive, and that's what matters right now for wheezy; that means r0 but also later point releases. Mraw, KiBi. signature.asc Description: Digital signature
Bug#684128: failure to communicate
Quoting Thomas Goirand (z...@debian.org): But, are you seriously proposing that we leave the issue as-is ??? Of course. The issue is there since partman exists (about 2005, from memory) and has probably never prevented anyone to install Debian since then. So, yes, this issue will still be in wheezy. Hopefully, the issue will be fixed in jessie, though. signature.asc Description: Digital signature
Bug#684128: failure to communicate
On Thu, 4 Apr 2013 19:09:04 +0200 Christian PERRIER bubu...@debian.org wrote: This mail is a very good argument to confirm that overcomplicated methods to make your point will just fail. If you have a point to make it, make ti. Once. With facts. I supplied plenty of facts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#5 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#12 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#36 I even supplied patches, after I was invited to do so. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#66 The first was justly criticised on the grounds that it contained a bashism. I immediately corrected it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#88 It was stated that the time was not appropriate to introduce user-visible changes in the installer. I pointed out that my patch did not require any such thing, and that if it had been acceptable for the installer to operate for many years, and many Debian releases, without mentioning that it was using a definition of megabytes and gigabytes contrary to what technically knowledgeable people would expect, it could just as well operate in conformance with their expectations, and not mention that either. The only other objection raised was the danger of introducing regressions. I supplied test scripts which demonstrated that my code produced results which were byte-for-byte identical to the existing code when operating in decimal mode, and offered to write tests for binary mode if anybody could suggest what would be accepted as proof of correctness. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#103 I was polite to everyone involved in the discussion, and answered every question put to me. Then I waited to see if anything would happen, or any further comment would be made. For eight months. You will never convince anyone with a mail like yours. If Debian bug report #684128 proves anything, it is that you will never convince anyone with technical argument, facts advanced in support of it, patches which completely solve the problem, test scripts which prove non-regression of those patches, and answering every single question or objection advanced regarding any of this. All of that will be completely ignored, without further comment. If you then attempt, as a last resort, to reason by way of analogy, this message will be categorized as spam and disappear into thin air. Perhaps there's some new and improved way of convincing people that I'm just unaware of. If so, tutorial references would be appreciated. Sorry, but this is only about failure to communicate. Well, that's certainly clear. As I said, I've tried everything I can think of. I'm out. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684128: failure to communicate
Quoting ian_br...@fastmail.net (ian_br...@fastmail.net): If Debian bug report #684128 proves anything, it is that you will never convince anyone with technical argument, facts advanced in support of Sorry, but Debian bug #684128 only proves one thing : that we (the D-I team) were mostly trying to release an installer for wheezy during the last 8 monthsand that the proposed changes were not judged as suitable for wheezyas nobody picked them up. Nothing proves that the patches you proposed will be ignored *after* the release of wheezy. Frankly speaking, given the current manpower in the D-I team, it might need help to get them in, mostly by reminding us *on time*, and factually, that these patches are here. D-I has several dozens of components, each with a few dozens of bugsseveral probably with working patches that only need someone in the team to have enough time and his|her attention focused on them. I perfectly understand you can be frustrated but, honestly, as of now, we're focused on the wheezy release, again. Fixing debootstrap has much more importance than Giga/Gibibytes. Once wheezy is released, I see no reason for your proposed patch to be rejected. But, again, the best way to remind this to us is a simple mail like Hello, folks, may I remind you about this patch and proposed fix? Would you consider it for jessie?. No need for dozens of line of irony whichbeing (most of us in the D-I team) non native speakers of English...we won't even understand..:-) signature.asc Description: Digital signature
