Bug#927680: marked as done (Code name spelling (upper/lower) is used inconsistently in Debian communication/documentation)
Your message dated Fri, 20 Sep 2019 20:04:10 +0200 with message-id <6e804e06-5ea5-57d9-0fe4-74a750e6e...@debian.org> and subject line Re: Code name spelling (upper/lower) is used inconsistently in Debian communication/documentation has caused the Debian Bug report #927680, regarding Code name spelling (upper/lower) is used inconsistently in Debian communication/documentation to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 927680: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927680 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: minor X-Debbugs-CC: debian-public...@lists.debian.org, debian-...@lists.debian.org, debian-...@lists.debian.org On Sb, 20 apr 19, 21:11:09, Justin B Rye wrote: > > But I've given up trying to get this sorted out, just as I've given up > asking why it is that we write "stretch" when the release announcement > called it "Stretch" and it's named after something called "Stretch"! Dear Release Team, Apparently the code name for Debian releases has been used inconsistently in various documentation and communication. As the team delegated to (among many others) decide the code name of Debian releases please kindly rule on the correct spelling (lower or upper case), i.e. 'buster' or 'Buster'. Many thanks, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi, On Sun, 21 Apr 2019 08:18:26 +0300 Andrei POPESCU wrote: > As the team delegated to (among many others) decide the code name of > Debian releases please kindly rule on the correct spelling (lower or > upper case), i.e. 'buster' or 'Buster'. It's lower case. http://meetbot.debian.net/debian-release/2019/debian-release.2019-08-28-19.05.html Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#927680: Code name spelling (upper/lower) is used inconsistently in Debian communication/documentation
Package: release.debian.org Severity: minor X-Debbugs-CC: debian-public...@lists.debian.org, debian-...@lists.debian.org, debian-...@lists.debian.org On Sb, 20 apr 19, 21:11:09, Justin B Rye wrote: > > But I've given up trying to get this sorted out, just as I've given up > asking why it is that we write "stretch" when the release announcement > called it "Stretch" and it's named after something called "Stretch"! Dear Release Team, Apparently the code name for Debian releases has been used inconsistently in various documentation and communication. As the team delegated to (among many others) decide the code name of Debian releases please kindly rule on the correct spelling (lower or upper case), i.e. 'buster' or 'Buster'. Many thanks, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Communication
On Sun, 2012-07-15 at 16:59 +0200, Cyril Brulebois wrote: I would be very pleased if you could communicate a little about your unblocks. Particularly, tasksel is a /slightly/ delicate package as we're trying to get d-i beta 1 out. Unblocking it without talking to anyone about it really isn't appreciated. There's also at least one (that I know of) that has an open unblock bug. The existing unblock hint for it also means that it will currently hit testing in tonight's britney run, which may or may not be a good plan given that the substantive changes have just been referred to the tech-ctte... Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1342640935.13812.83.ca...@jacala.jungle.funky-badger.org
Re: Communication
On Sun, Jul 15, 2012 at 23:09:41 +0200, Luk Claes wrote: On 07/15/2012 04:59 PM, Cyril Brulebois wrote: Hi Luk, Hi KiBi I would be very pleased if you could communicate a little about your unblocks. Particularly, tasksel is a /slightly/ delicate package as we're trying to get d-i beta 1 out. Unblocking it without talking to anyone about it really isn't appreciated. I unblocked it as it fixes an RC bug and the diff seems reasonable. Should I comment to unblock for now? It's probably ok in this particular case, but it doesn't fit under the RC bug fixes (without other more involved changes) heading you used. Neither do a fair number of your other unblocks. So please ask first next time. Cheers, Julien signature.asc Description: Digital signature
Communication
Hi Luk, I would be very pleased if you could communicate a little about your unblocks. Particularly, tasksel is a /slightly/ delicate package as we're trying to get d-i beta 1 out. Unblocking it without talking to anyone about it really isn't appreciated. Mraw, KiBi. signature.asc Description: Digital signature
Re: Communication
On 07/15/2012 04:59 PM, Cyril Brulebois wrote: Hi Luk, Hi KiBi I would be very pleased if you could communicate a little about your unblocks. Particularly, tasksel is a /slightly/ delicate package as we're trying to get d-i beta 1 out. Unblocking it without talking to anyone about it really isn't appreciated. I unblocked it as it fixes an RC bug and the diff seems reasonable. Should I comment to unblock for now? Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50033195.1000...@debian.org
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 07:08 PM, Moritz Muehlenhoff wrote: On Wed, Sep 08, 2010 at 03:22:29PM +0200, Julien Cristau wrote: from now, and as far as I know neither the security team nor the stable release managers usually accept that kind of changes in stable. If they say they'll be happy to accept random chromium code dumps in released squeeze, The plan for Chromium is to update it with the Chromium stable releases, i.e. the same way Xulrunner has been updated during the supported life time of xulrunner 1.9.0. Once these updates have stopped, the plan is apply backported patches (again, like xulrunner is handled for lenny). During our meeting, we discussed this specific case and we ended up with: If the Security Team accepts to support it during Squeeze, we can have it in Squeeze. Nevertheless, we'll add a note about its support in the Release Notes. I'll add the necessary unblock hint to have it back in testing. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca7b0e6.5050...@debian.org
Re: chromium not in Squeeze: a bit of communication needed?
On 09/15/2010 08:23 PM, Mehdi Dogguy wrote: I think it's easy to see if we will have to accept a new major release of Chromium in Squeeze (after its release): Would you be able to backport any fix from 6.x to 3.x? If they keep releasing every 3 months, you'll have to deal with a more distant release. Their official blog [3] has an interesting post about how they plan to release future stable versions. And, quite frankly, it doesn't look brilliant. [3] http://blog.chromium.org/2010/07/release-early-release-often.html Furthermore, I don't see any page speaking about support of former stable releases. So, I assume there is none. The newest is always the only one “supported”. If we consider accepting Chromium in Squeeze, we should be ready to accept new big dumps of Chromium (not only bugfixes… because, that's not how they used to release) without even looking at the diff. If we do so, we should leave a remark about how the security support and updates are handled for Chromium in Squeeze in the Release Notes (stating clearly that Chromium is an exception and why). If we're going to EOL Chromium during Squeeze's lifecycle (and I believe it will happen quite soon), then why should we accept it in Squeeze at all? We already know that they haven't a LTS. I never wrote I intend to propose a new major release in Squeeze (after its release). I wrote many times that I volunteer to support and backport security patches, like Mike will do with iceweasel/xulrunner (as far as I know official security support for firefox 3.5.x is going to be terminated) Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 07:08 PM, Moritz Muehlenhoff wrote: On Wed, Sep 08, 2010 at 03:22:29PM +0200, Julien Cristau wrote: from now, and as far as I know neither the security team nor the stable release managers usually accept that kind of changes in stable. If they say they'll be happy to accept random chromium code dumps in released squeeze, The plan for Chromium is to update it with the Chromium stable releases, i.e. the same way Xulrunner has been updated during the supported life time of xulrunner 1.9.0. Once these updates have stopped, the plan is apply backported patches (again, like xulrunner is handled for lenny). SRMs, would you accept such updates? Besides, Giuseppe said that Chromium 5.x wasn't an option for Squeeze and uploaded Chromium 6.x. Why this won't happen again during the freeze? or worst, during Squeeze's lifetime? Those are the only blockers for Chromium in Squeeze, I guess. If we can sort them out, we'll unblock chromium. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8f9b1f.7090...@debian.org
Re: chromium not in Squeeze: a bit of communication needed?
On 09/14/2010 05:56 PM, Mehdi Dogguy wrote: Besides, Giuseppe said that Chromium 5.x wasn't an option for Squeeze and uploaded Chromium 6.x. Why this won't happen again during the freeze? or worst, during Squeeze's lifetime? As I wrote many times, no one can say if this will happen again. However I read from Josselin Mouette that the 1.2 branch should have a long term support, so I suppose this is improbable. I can certainly say that if it will happen during Squeeze's lifetime, this is a problem for all webkit related code, not only for chromium. BTW if you will reconsider the inclusion in Squeeze, Like Mozilla products, when the support will be no longer feasible we will announce the end of security support (as I wrote in #593919). Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 07:08:29PM +0200, Moritz Muehlenhoff wrote:
The plan for Chromium is to update it with the Chromium stable releases, i.e.
the same way Xulrunner has been updated during the supported life time of
xulrunner 1.9.0. Once these updates have stopped, the plan is apply
backported patches (again, like xulrunner is handled for lenny).
Thanks for this data point Moritz! I guess this settles the part about
security team support, which can be counted upon. Of course that alone
does not mean that we should have Chromium back: the package is not in
testing at present and will need to enter back, if ever, according to
usual release team policies. At least, we now have one doubt less :-).
Cheers.
PS regarding the other part of this thread about how to support, via
backports, what I would call rapidly evolving end-user apps, it is
surely a worthwhile discussion, more general than Chromium. I believe
it would be worth to have it elsewhere (e.g. -devel), possibly once
the needed feature requests (e.g. on APT) have been implemented. Note
that unless there is a chance to get those features into Squeeze,
it's probably a too-late-coming discussion.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100909100056.ga9...@upsilon.cc
chromium not in Squeeze: a bit of communication needed?
I've been following the chromium-browser saga a bit, who has ended up
with the removal of the package from testing [1,2]. While I'm a
chromium-browser user myself, and hence I'm saddened of seeing it go,
I'm not here to question the choice as I'm sure it's been made as the
right one and that it hasn't been an easy one to make.
[1] http://lists.debian.org/debian-release/2010/09/msg00582.html
[2]
http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/
Still I think we need, as Debian, to communicate about that choice. As
you can imagine, I particularly care about that as sooner or later
someone will ask me « why Debian doesn't ship Chromium? », and I'd like
to know the right answer to that question, so that I can provide it,
rather than offering my personal view only :-)
That's all I care about. [3]
From the exchange on -release, I *guess* that the reason is that
Chromium 5 is not meant to be supportable security-wise and at the same
time that it's too late to get Chromium 6 into Squeeze. If this is the
case, I welcome explicit comments in that direction by the security and
release teams. If there are other reasons, please let me know.
Such an answer will be even more useful as, say, a kind of public
statement toward upstream, explaining why their practices are not
something that suite the quality requirements we have in Debian.
Many thanks in advance to all involved teams, and in particular to
Giuseppe who put a shitload of work in the packaging.
Please help me out in answering tricky questions like this one!
Cheers.
[3] A question you might have at this point is: why you bother about
Chromium and not other packages?. Well, I do bother about all
packages and I'm just trying to anticipate questions I'll might be
asked as soon as Squeeze get released. For instance and for the same
reason, I've proposed just yesterday to mention the removal of Plone
from Squeeze, and the maintainer has kindly agreed to explain the
reasons in the Squeeze release notes. So, I'm not special casing
anything here, and I encourage you to point me to other similar
cases.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908114849.ga7...@upsilon.cc
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote: [3] A question you might have at this point is: why you bother about Chromium and not other packages?. Well, I do bother about all packages and I'm just trying to anticipate questions I'll might be asked as soon as Squeeze get released. For instance and for the same reason, I've proposed just yesterday to mention the removal of Plone from Squeeze, and the maintainer has kindly agreed to explain the reasons in the Squeeze release notes. So, I'm not special casing anything here, and I encourage you to point me to other similar cases. I think a section of the release notes should include such information. It could also include hints at what we plan to do. I don't know what Giuseppe plans for chromium, but I for one plan to upload newer versions of iceweasel as soon as I can (which might not be as soon as one could hope, due to the xulrunner transition that goes with it). Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908121103.ga31...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 02:11:03PM +0200, Mike Hommey wrote: On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote: [3] A question you might have at this point is: why you bother about Chromium and not other packages?. Well, I do bother about all packages and I'm just trying to anticipate questions I'll might be asked as soon as Squeeze get released. For instance and for the same reason, I've proposed just yesterday to mention the removal of Plone from Squeeze, and the maintainer has kindly agreed to explain the reasons in the Squeeze release notes. So, I'm not special casing anything here, and I encourage you to point me to other similar cases. I think a section of the release notes should include such information. It could also include hints at what we plan to do. I don't know what Giuseppe plans for chromium, but I for one plan to upload newer versions of iceweasel as soon as I can (which might not be as soon as one could hope, due to the xulrunner transition that goes with it). into backports, that is. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908130618.ga...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 8, 2010 at 13:48:49 +0200, Stefano Zacchiroli wrote: I've been following the chromium-browser saga a bit, who has ended up with the removal of the package from testing [1,2]. While I'm a chromium-browser user myself, and hence I'm saddened of seeing it go, I'm not here to question the choice as I'm sure it's been made as the right one and that it hasn't been an easy one to make. We were given a choice between removing chromium-browser from testing, or accepting a diff of 22161 files changed, 8494803 insertions(+), 1202268 deletions(-) That didn't seem like much of a choice. I don't have any reason to believe the new version won't have the same problem 2 months (or a year) from now, and as far as I know neither the security team nor the stable release managers usually accept that kind of changes in stable. If they say they'll be happy to accept random chromium code dumps in released squeeze, then I guess we can let it back in, but until then I don't think keeping a version the maintainer doesn't want to support in testing helps anyone. Cheers, Julien signature.asc Description: Digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 03:22 PM, Julien Cristau wrote: I don't have any reason to believe the new version won't have the same problem 2 months (or a year) from now Note that this isn't a chromium specific issue, please see the opened issues in webkit: http://security-tracker.debian.org/tracker/source-package/webkit Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 03:22 PM, Julien Cristau wrote: and as far as I know neither the security team nor the stable release managers usually accept that kind of changes in stable. If they say they'll be happy to accept random chromium code dumps in released squeeze, then I guess we can let it back in, but until then I don't think keeping a version the maintainer doesn't want to support in testing helps anyone. I never wrote that I will propose random chromium code dumps in released squeeze, I wrote I plan to backport security fixes and for this reason I realized that backporting patches in chromium 5 is not feasible. Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote: I've been following the chromium-browser saga a bit, who has ended up with the removal of the package from testing [1,2]. While I'm a chromium-browser user myself, and hence I'm saddened of seeing it go, I'm not here to question the choice as I'm sure it's been made as the right one and that it hasn't been an easy one to make. [1] http://lists.debian.org/debian-release/2010/09/msg00582.html [2] http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/ Still I think we need, as Debian, to communicate about that choice. As you can imagine, I particularly care about that as sooner or later someone will ask me « why Debian doesn't ship Chromium? », and I'd like to know the right answer to that question, so that I can provide it, rather than offering my personal view only :-) That's all I care about. [3] I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. That is of course assuming someone is willing to support the backport. I may do that if Giuseppe isn't interested. Having chromium not present in stable proper helps the security team immensely. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908101035.d733418c.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 15:58:17 +0200, Giuseppe Iuculano wrote: On 09/08/2010 03:22 PM, Julien Cristau wrote: I don't have any reason to believe the new version won't have the same problem 2 months (or a year) from now Note that this isn't a chromium specific issue, please see the opened issues in webkit: http://security-tracker.debian.org/tracker/source-package/webkit That isn't a very good list wrt to squeeze's webkit since that includes the multitude of lenny issues. See [0] of which half of the webkit issues still open i've commited fixes to git last night, and hopefully a new package will be uploaded soon. Best wishes, Mike [0] http://security-tracker.debian.org/tracker/status/release/unstable?show_undetermined_urgency=1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908101528.a2ba539b.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 16:23:59 +0200, Giuseppe Iuculano wrote: On 09/08/2010 04:15 PM, Michael Gilbert wrote: That isn't a very good list wrt to squeeze's webkit since that includes the multitude of lenny issues. That was the point, the number of webkit opened issues in lenny. That isn't really a fair comparison. I campaigned (unsuccessfully) to keep webkit out of lenny at the time since it was so experimental/unsupportable. Thus I had no interest in supporting that. However, I'm planning to help support webkit in squeeze, so I don't foresee such an issue in the future. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908102616.42b7f7c1.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On 2010-09-08 16:10 +0200, Michael Gilbert wrote: On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote: I've been following the chromium-browser saga a bit, who has ended up with the removal of the package from testing [1,2]. While I'm a chromium-browser user myself, and hence I'm saddened of seeing it go, I'm not here to question the choice as I'm sure it's been made as the right one and that it hasn't been an easy one to make. [1] http://lists.debian.org/debian-release/2010/09/msg00582.html [2] http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/ Still I think we need, as Debian, to communicate about that choice. As you can imagine, I particularly care about that as sooner or later someone will ask me « why Debian doesn't ship Chromium? », and I'd like to know the right answer to that question, so that I can provide it, rather than offering my personal view only :-) That's all I care about. [3] I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. That is of course assuming someone is willing to support the backport. It also means that users need to be taught how to change the apt pinning priority for backports, because in the default configuration backported packages are never updated automatically. Which is very bad from a security point of view. Sven -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwxkmgib@turtle.gmx.de
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 04:26 PM, Michael Gilbert wrote: That isn't really a fair comparison. I campaigned (unsuccessfully) to keep webkit out of lenny at the time since it was so experimental/unsupportable. Thus I had no interest in supporting that. However, I'm planning to help support webkit in squeeze, so I don't foresee such an issue in the future. Ok, so you campaigned to keep webkit out of lenny because now it is unsupportable. Now I have the same question you made for chromium. Are you sure this will not happen again? Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 16:55:40 +0200, Sven Joachim wrote: On 2010-09-08 16:10 +0200, Michael Gilbert wrote: On Wed, 8 Sep 2010 13:48:49 +0200, Stefano Zacchiroli wrote: I've been following the chromium-browser saga a bit, who has ended up with the removal of the package from testing [1,2]. While I'm a chromium-browser user myself, and hence I'm saddened of seeing it go, I'm not here to question the choice as I'm sure it's been made as the right one and that it hasn't been an easy one to make. [1] http://lists.debian.org/debian-release/2010/09/msg00582.html [2] http://www.iuculano.it/en/linux/debian/chromium-browser-removed-from-testing/ Still I think we need, as Debian, to communicate about that choice. As you can imagine, I particularly care about that as sooner or later someone will ask me « why Debian doesn't ship Chromium? », and I'd like to know the right answer to that question, so that I can provide it, rather than offering my personal view only :-) That's all I care about. [3] I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. That is of course assuming someone is willing to support the backport. It also means that users need to be taught how to change the apt pinning priority for backports, because in the default configuration backported packages are never updated automatically. Which is very bad from a security point of view. So, I think the solution for that is relatively straightforward. I think that an important part of making backports official would be adding an option to the installer that automatically sets up backports in the sources.list with a reasonable priority (similar to what is done for volatile and security now). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908110210.930e8bc9.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 17:02:33 +0200, Giuseppe Iuculano wrote: On 09/08/2010 04:26 PM, Michael Gilbert wrote: That isn't really a fair comparison. I campaigned (unsuccessfully) to keep webkit out of lenny at the time since it was so experimental/unsupportable. Thus I had no interest in supporting that. However, I'm planning to help support webkit in squeeze, so I don't foresee such an issue in the future. Ok, so you campaigned to keep webkit out of lenny because now it is unsupportable. Now I have the same question you made for chromium. Are you sure this will not happen again? I campaigned to keep webkit out of lenny because I foresaw it as unsupportable then (and now we have evidence that confirms that). I think its come a long way since then, and I think it is indeed supportable now for squeeze. On the other hand, I don't think chromium is supportable yet, which is why I don't think it should be in squeeze. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908110457.07015063.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 05:04 PM, Michael Gilbert wrote: I think it is indeed supportable now for squeeze. What was changed from lenny to now? Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 8, 2010 at 5:55 PM, Sven Joachim svenj...@gmx.de wrote: On 2010-09-08 16:10 +0200, Michael Gilbert wrote: I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. That is of course assuming someone is willing to support the backport. It also means that users need to be taught how to change the apt pinning priority for backports, because in the default configuration backported packages are never updated automatically. Which is very bad from a security point of view. Yes, but it is not the best solution. Someone already proposed in another thread (about 'backports') to change the default archive pin from '1' to '200' (in fact any value =100 and 500, 200 is just my favorite) so that packages from backports will still have a lower priority over the packages from stable/security/volatile but also to be able to install them without pinning all the involved packages if the package only exists on backports. Thanks -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimwyzvxrtt1esbs2pkutct7nkyxx1pdybozt...@mail.gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 17:09:32 +0200, Giuseppe Iuculano wrote: On 09/08/2010 05:04 PM, Michael Gilbert wrote: I think it is indeed supportable now for squeeze. What was changed from lenny to now? The are now many very usable webkit frontends, which I can use on a daily basis, so I now have interest in using webkit itself, and thus have interest in closing security issues; whereas with lenny there is no usable frontend, and thus no reason for anyone to be interested in security support. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908111558.935f2781.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
Le mercredi 08 septembre 2010 à 17:09 +0200, Giuseppe Iuculano a écrit : On 09/08/2010 05:04 PM, Michael Gilbert wrote: I think it is indeed supportable now for squeeze. What was changed from lenny to now? What has changed is that webkit is widely deployed inside and outside Debian, and for that has undergone a large scrutiny that got rid of much maintainability issues. Furthermore we are shipping the 1.2 branch in squeeze, for which upstream has explicitly committed to long term support. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283959080.22754.1.ca...@meh
Re: chromium not in Squeeze: a bit of communication needed?
Michael Gilbert wrote: I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. Do you really think that desktop users[1] should be expected to learn about backports, and manually configure them, and learn how to convince apt to install from them, in order to get the best web browser available[2]? If the preceding sounds simple, think again; you're suggesting that users have to either dig up some faq or forum post, or post to debian-user, just in order to get a good web browser. If backports are really officially supported, and we encourage users to install a web browser from them, which is not available in stable, how is that truely different than shipping the same web browser in stable? AFAICS the only difference is that only 10 to 25% [3] of users will find the web browser in backports, while some other percentage will install Ubuntu instead. The security team will still be left responsible for supporting the former users' systems. (BTW, have you considered that apt does not automatically upgrade packages installed from backports? That the majority of documentation, including the documentation on wiki.debian.org, about installing flashplugin-nonfree from backports does not take this into account, and will leave the user with a never-upgraded package?) -- see shy jo [1] As opposed to the server administrators who seem to be backports' main current audience. [2] Chromium or iceweasel; take your pick since backports is being suggested as a delivery mechanism for both. [3] Estimate based roughly on percentage of stable users who manage to install flashplugin-nonfree, whose installation is similarly obfuscated. signature.asc Description: Digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 05:17:55PM +0200, Josselin Mouette wrote: Le mercredi 08 septembre 2010 à 17:09 +0200, Giuseppe Iuculano a écrit : On 09/08/2010 05:04 PM, Michael Gilbert wrote: I think it is indeed supportable now for squeeze. What was changed from lenny to now? What has changed is that webkit is widely deployed inside and outside Debian, and for that has undergone a large scrutiny that got rid of much maintainability issues. Furthermore we are shipping the 1.2 branch in squeeze, for which upstream has explicitly committed to long term support. *hum* the 1.0 branch was supposed to come with long term support, too. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908152647.gb2...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 11:14:33AM -0400, Joey Hess wrote: [2] Chromium or iceweasel; take your pick since backports is being suggested as a delivery mechanism for both. There is a difference with Iceweasel, though, in that squeeze will ship with Iceweasel. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908153039.gc2...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 8 Sep 2010 11:14:33 -0400, Joey Hess wrote: Michael Gilbert wrote: I think that this need is justification to declare backports officially supported by the debian project. Thus when asked this question, you can point to the fact that chromium is indeed supported on stable, just via a different model than folks are used to. Do you really think that desktop users[1] should be expected to learn about backports, and manually configure them, and learn how to convince apt to install from them, in order to get the best web browser available[2]? If the preceding sounds simple, think again; you're suggesting that users have to either dig up some faq or forum post, or post to debian-user, just in order to get a good web browser. A an option in the installer like volatile/security should address a lot of this concern. If backports are really officially supported, and we encourage users to install a web browser from them, which is not available in stable, how is that truely different than shipping the same web browser in stable? The difference is that there is no arduous backporting/dsa process to push that update, and as an added benefit, it gets a ton of testing by going through unstable/testing first. Plus, there is a subset of users that want to always have the latest/greatest browser, and stable can never meet that need. AFAICS the only difference is that only 10 to 25% [3] of users will find the web browser in backports, while some other percentage will install Ubuntu instead. The security team will still be left responsible for supporting the former users' systems. Adding an option in the installer would significantly help discoverability. (BTW, have you considered that apt does not automatically upgrade packages installed from backports? That the majority of documentation, including the documentation on wiki.debian.org, about installing flashplugin-nonfree from backports does not take this into account, and will leave the user with a never-upgraded package?) Maybe the decision about backports priority should be reconsidered? Give it an appropriately higher priority due to its official nature now. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908113429.e1f18c56.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On 09/08/2010 05:15 PM, Michael Gilbert wrote: I now have interest in using webkit itself, and thus have interest in closing security issues; whereas with lenny there is no usable frontend, and thus no reason for anyone to be interested in security support. I think it is more honest to say that webkit in lenny has a lot of opened issue because backporting is a pain, and not because you haven't interest in fixing them. Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 08 Sep 2010 17:42:37 +0200, Giuseppe Iuculano wrote: On 09/08/2010 05:15 PM, Michael Gilbert wrote: I now have interest in using webkit itself, and thus have interest in closing security issues; whereas with lenny there is no usable frontend, and thus no reason for anyone to be interested in security support. I think it is more honest to say that webkit in lenny has a lot of opened issue because backporting is a pain, and not because you haven't interest in fixing them. No, my interest right now is removing webkit from lenny because no one has any interest in using/supporting it there. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908114328.22327289.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
Michael Gilbert wrote: A an option in the installer like volatile/security should address a lot of this concern. Unless it installs the package from backports, the most the installer can do is eliminate one or two of the three or four things users must do to use it. All my comments about user discoverability/usability still apply. If backports are really officially supported, and we encourage users to install a web browser from them, which is not available in stable, how is that truely different than shipping the same web browser in stable? The difference is that there is no arduous backporting/dsa process to push that update If we're encouraging users to install a web browser from an officially supported part of Debian, then the security support requirements are not lessened *at all*. -- see shy jo signature.asc Description: Digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 12:19:40PM -0400, Joey Hess wrote: Michael Gilbert wrote: A an option in the installer like volatile/security should address a lot of this concern. Unless it installs the package from backports, the most the installer can do is eliminate one or two of the three or four things users must do to use it. All my comments about user discoverability/usability still apply. If backports are really officially supported, and we encourage users to install a web browser from them, which is not available in stable, how is that truely different than shipping the same web browser in stable? The difference is that there is no arduous backporting/dsa process to push that update If we're encouraging users to install a web browser from an officially supported part of Debian, then the security support requirements are not lessened *at all*. Arguably, it's easier to get newest releases of the software as security support into testing and thus backports, than it is to get them in stable. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908164117.gb3...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 8 Sep 2010 12:19:40 -0400, Joey Hess wrote: Michael Gilbert wrote: A an option in the installer like volatile/security should address a lot of this concern. Unless it installs the package from backports, the most the installer can do is eliminate one or two of the three or four things users must do to use it. All my comments about user discoverability/usability still apply. Here's what I think could be done: 1. Provide debian-backports-desktop which has a limited set of bleeding edge packages that desktop users want 2. Make the priority of this release higher than that of stable, and have some high standards for the ftpmaster to control what gets in 3. Provide debian-backports-server which is the current backports, just renamed, and operates the same way 4. Provide an option in the installer called I want bleeding edge desktop updates (provided via debian-backports-desktop) 5. Provide an option called I want server backports (provided via debian-backports-server) If backports are really officially supported, and we encourage users to install a web browser from them, which is not available in stable, how is that truely different than shipping the same web browser in stable? The difference is that there is no arduous backporting/dsa process to push that update If we're encouraging users to install a web browser from an officially supported part of Debian, then the security support requirements are not lessened *at all*. Testing is currently declared officially supported and those updates go through the same unstable-testing process proposed here. They receive no announcement other than the automated daily testing security postings [0]. Perhaps those announcements could be made a bit more professional, and perhaps done on a per-package basis. It may also be that they should be posted to debian-security-announce as well. Best wishes, Mike [0] http://lists.debian.org/debian-testing-security-announce/2010/09/threads.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908125728.48380d5f.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 03:22:29PM +0200, Julien Cristau wrote: from now, and as far as I know neither the security team nor the stable release managers usually accept that kind of changes in stable. If they say they'll be happy to accept random chromium code dumps in released squeeze, The plan for Chromium is to update it with the Chromium stable releases, i.e. the same way Xulrunner has been updated during the supported life time of xulrunner 1.9.0. Once these updates have stopped, the plan is apply backported patches (again, like xulrunner is handled for lenny). Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908170829.ga22...@inutil.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 8 Sep 2010 12:57:28 -0400, Michael Gilbert wrote: On Wed, 8 Sep 2010 12:19:40 -0400, Joey Hess wrote: Michael Gilbert wrote: A an option in the installer like volatile/security should address a lot of this concern. Unless it installs the package from backports, the most the installer can do is eliminate one or two of the three or four things users must do to use it. All my comments about user discoverability/usability still apply. Here's what I think could be done: 1. Provide debian-backports-desktop which has a limited set of bleeding edge packages that desktop users want 2. Make the priority of this release higher than that of stable, and have some high standards for the ftpmaster to control what gets in 3. Provide debian-backports-server which is the current backports, just renamed, and operates the same way 4. Provide an option in the installer called I want bleeding edge desktop updates (provided via debian-backports-desktop) 5. Provide an option called I want server backports (provided via debian-backports-server) This solution may be more complicated than necessary. I just re-read backports' documentation. It looks like automatic updates are prevented due to the use of the 'NotAutomatic' flag in the release file. I'd be interested in understanding the logic for that setting and debating whether it could be disabled. As for the need for pinning, that can be solved by judiciously choosing package names. The current instructions say to append '~bpo' to all packages, which makes backport versions older than stable versions. For chromium and other fast-moving packages that should stay up to date, the instructions could say to use '+bpo' which would make that a newer version than stable. Again, it should be up to the ftpmaster to review and OK (via request) all '+bpo' uploads due to the risk of breakage on automatic updates. Combine this solution with disabling 'NotAutomatic', and I think all of the concerns are addressed. Thoughts? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908141526.eec0b342.michael.s.gilb...@gmail.com
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 8, 2010 at 14:15:26 -0400, Michael Gilbert wrote: As for the need for pinning, that can be solved by judiciously choosing package names. The current instructions say to append '~bpo' to all packages, which makes backport versions older than stable versions. For chromium and other fast-moving packages that should stay up to date, the instructions could say to use '+bpo' which would make that a newer version than stable. Again, it should be up to the ftpmaster to review and OK (via request) all '+bpo' uploads due to the risk of breakage on automatic updates. Combine this solution with disabling 'NotAutomatic', and I think all of the concerns are addressed. Thoughts? That makes absolutely no sense. Package names and package version numbers are not the same thing. And backports already have higher versions than stable, that's kind of the whole point. Cheers, Julien signature.asc Description: Digital signature
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, 8 Sep 2010 20:30:21 +0200, Julien Cristau wrote: On Wed, Sep 8, 2010 at 14:15:26 -0400, Michael Gilbert wrote: As for the need for pinning, that can be solved by judiciously choosing package names. The current instructions say to append '~bpo' to all packages, which makes backport versions older than stable versions. For chromium and other fast-moving packages that should stay up to date, the instructions could say to use '+bpo' which would make that a newer version than stable. Again, it should be up to the ftpmaster to review and OK (via request) all '+bpo' uploads due to the risk of breakage on automatic updates. Combine this solution with disabling 'NotAutomatic', and I think all of the concerns are addressed. Thoughts? That makes absolutely no sense. Package names and package version numbers are not the same thing. And backports already have higher versions than stable, that's kind of the whole point. Right. It would require backport uploads to have versions something like stable version+bpo-testing version for stuff that should automatically update and stable version~bpo-testing version, but that's just messy. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908143315.0db74d6c.michael.s.gilb...@gmail.com
Communication style (Was: unblock request for consolekit_0.2.10-2)
[Marc 'HE' Brockschmidt] If you continue to ignore our widely announced rules, then yeah, you waste your time. And ours. Here again, yet another insulting message to one of your fellow debian developer. I wonder if this is how the release team wish to communicate with the rest of the developers, or if the style you choose towards me is unique for us two. I hope for the latter, because I want Lenny released on time and not delayed because too few people are interested in working on preparing it, and insulting the ones that could help out seem a bad strategy. The effect of your insult on me is demotivating regarding assisting the release team. Still not sure if this is the intended effect. The alternative seem to be that you do not know that your message is insulting, that I misunderstood the text and that it can be read in a way that isn't insulting, or that you believe your insult will have positive effect towards the Lenny release. The least depressing alternative seem to be me misunderstanding your message, so I will cling to the hope that it is all in my head, while making you aware that your message seemed insulting to me. Just for the record, as I see it, I understand how the freeze work, and have not ignored any widely announced rules. Those are only your insulting claims towards me. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Communication style (Was: unblock request for consolekit_0.2.10-2)
Petter Reinholdtsen wrote: [Marc 'HE' Brockschmidt] If you continue to ignore our widely announced rules, then yeah, you waste your time. And ours. Here again, yet another insulting message to one of your fellow debian developer. I wonder if this is how the release team wish to communicate with the rest of the developers, or if the style you choose towards me is unique for us two. I hope for the latter, because I want Lenny released on time and not delayed because too few people are interested in working on preparing it, and insulting the ones that could help out seem a bad strategy. I don't think this was meant to be insulting at all, though I do understand that it can be interpreted that way... so sorry for that. Just for the record, as I see it, I understand how the freeze work, and have not ignored any widely announced rules. Those are only your insulting claims towards me. 90 files changed, 19555 insertions(+), 10427 deletions(-) Which of these changes are really needed and would you like us to review? It seems you want to use new features that resulted in major code changes in the package. As we are currently stabilising the release, these are normally not accepted anymore. You could compare the current state with a stable prerelease were bugfixes that would be accepted for a stable point release can flow in every day. The freeze guidelines do make it easier to get even other fixes in, but these are meant to be the exception... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
about the communication style (Re: #380360)
severity 380360 wishlist thanks so apparently this is a non-issue. I do hope that a comment on irc We also need to have a chat at some point about python-minimal in general is not the general style used by the release team to start a discussion about the RC severity of bug reports. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
