Re: Rethinking stable updates policy
On Fri, Aug 25, 2006 at 04:45:31PM -0500, John Goerzen wrote: I think it's time we reopen the discussion on what stable means and what it should mean. To start with, [1] says that a package is only uploaded to stable when it meets one of these criteria: * it fixes a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package I would love to have the new package for stable eases future update as this would allow to fix stable issues which would otherwise cause future grief to fix. For example, a more allowing policy would allow exim 3 to warn against new installations and in turn motivate people to update to exim3 before they take the etch plunge. Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support * Infrastructure updates such as ClamAV and Spamassassin * Security and other important Firefox updates I think we have volatile for this, allowing people to choose whether they need absolute stability or new infrastructure. 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 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Il giorno ven, 25/08/2006 alle 16.45 -0500, John Goerzen ha scritto: * Updates must undergo testing, ideally with peer review This could be impossible if stable and testing distributions are binary-incompatible (ie. using different versions of glibc), just like sarge and etch are in this moment. Anyway, I mostly agree with your proposal, even if some of the points you raised can be achieved using volatile. -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa รจ una parte del messaggio firmata digitalmente
Re: Rethinking stable updates policy
John Goerzen wrote: Hello, The Debian stable distribution has been a thorn in our side for a long time. We tend to go a long time between releases, which means that stable grows less and less useful as time goes on. We also have a strict policy on what is allowed into stable. This policy has many merits, especially for those running Debian on production servers. On the other hand, it has many problems. One is that current Debian stable can't be installed on many current systems due to weak SATA controller support. I think it's time we reopen the discussion on what stable means and what it should mean. To start with, [1] says that a package is only uploaded to stable when it meets one of these criteria: * it fixes a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package I am mainly interested in #1. I think we need to take a more expansive view of what constitutes a functionality problem, perhaps replacing truly critical with serious. Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with only security updates. Expecting this to become easier with new kernel versions included is a little bit off the reality. Feel free to try to get a new kernel via backports.org and watch how many other packages creep in. It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) * Infrastructure updates such as ClamAV and Spamassassin We already have this in form of the volatile archive. That's exactly what volatile is for and why it has been started. For these packages it works quite well. * Security and other important Firefox updates I'm sure you only forgot that we do have security updates for Mozilla and friends (thanks to the great work of Alexander Sack, can't say that often enough). Anyway, you want to see new versions, which is fine. However, this also requires new dependencies since newer versions tend to require newer libraries. Also there are a lot of translation and plugin packages that would have to be updated as well - and the software would behave differently. That's nothing for a *stable* Debian release. However, thanks to nobse there is the backports repository which is perfectly suited for such an effort. Not sure if anybody bothered to backport Mozilla and friends yet, though. (I guess not. Hint! Hint!) Now, we need also to make sure that stable stays stable, and should be introducing additional guidelines to accompany this: * No major architectural changes in packages (don't upgrade spamassassin from v2 to v3, but it may be OK to introduce a new spamassassin v3 package). Or, no XF86 - XOrg transition, but perhaps a new XF86 point release with more HW support could work This should not happen *in* the stable distribution since it would become a floating target instead. The cases you mentioned have already happened outside of the stable release, i.e. in the backports archive, iirc. * Updates must undergo testing, ideally with peer review For this we don't have the infrastructure with regards to stable, and it's also not possible to update stable just again because we noticed that Firefox creashes 50% of the time. Backports is much easier to handle for this and should be used. * Updates must be drop-in compatible with the released stable -- no config file incompatibilies or new debconf prompts, no new library so versions or deps on libraries not in stable, etc. This rejects packages like the kernel or Mozilla and friends already. It is important to maintain stable as stable for existing server installs, but still keep it useful for new deployments. I think we can achieve the latter without compromising the former, in a little better way that we have done to date. It's also important for desktop installations that shouldn't change every other day. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Marc Haber wrote: To start with, [1] says that a package is only uploaded to stable when it meets one of these criteria: * it fixes a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package I would love to have the new package for stable eases future update as this would allow to fix stable issues which would otherwise cause future grief to fix. For example, a more allowing policy would allow exim 3 to warn against new installations and in turn motivate people to update to exim3 before they take the etch plunge. Adding a warning *now* does not imply to *eases future update*. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: John Goerzen wrote: Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with only security updates. New kernel packages, and a rebuilt install image, yes. New utilities? Which utilities? The only one I'm aware of that breaks with newer kernels is udev, and hasn't that been fixed for awhile now? I've never had a problem taking a stable box and putting a nice shiny new kernel on it. Which utilities have to be updated here? I'm not talking about something like 2.4 to 2.6, just point releases within 2.6. It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) Well, a repo for updated ISOs would be more useful to people, I think. But again, when somebody goes to debian.org to download stable, they'll get something that doesn't work. It would be better to, say, issue 3.0.1 with a newer kernel package. This wouldn't even have to cause any impact at all to existing installations. * Infrastructure updates such as ClamAV and Spamassassin We already have this in form of the volatile archive. That's exactly what volatile is for and why it has been started. For these packages it works quite well. True, but it would be better to make it more official. Plus, are you going to stick X, PostgreSQL, and MySQL in volatile? * Security and other important Firefox updates I'm sure you only forgot that we do have security updates for Mozilla and friends (thanks to the great work of Alexander Sack, can't say that often enough). Quite right, sorry. Anyway, you want to see new versions, which is fine. However, this No, that's not a biggie to me. Now, we need also to make sure that stable stays stable, and should be introducing additional guidelines to accompany this: * No major architectural changes in packages (don't upgrade spamassassin from v2 to v3, but it may be OK to introduce a new spamassassin v3 package). Or, no XF86 - XOrg transition, but perhaps a new XF86 point release with more HW support could work This should not happen *in* the stable distribution since it would become a floating target instead. The cases you mentioned have already happened outside of the stable release, i.e. in the backports archive, iirc. Not the kernel, which is the most important and most troublesome piece. That part really needs to be supported directly at debian.org. * Updates must undergo testing, ideally with peer review For this we don't have the infrastructure with regards to stable, and it's also not possible to update stable just again because we noticed that Firefox creashes 50% of the time. Backports is much easier to handle for this and should be used. If this stays small-scale -- and it should -- this could be as simple as having, say, 5 trusted developers' GPG signatures on a message saying they have evaluated it against standard criteria and it passes. Doesn't have to be a massive thing. But you're right, we would absolutely want to make sure we get it right. It's a hurdle, but I wouldn't call it insurmountable. * Updates must be drop-in compatible with the released stable -- no config file incompatibilies or new debconf prompts, no new library so versions or deps on libraries not in stable, etc. This rejects packages like the kernel or Mozilla and friends already. Again, I am confused about why this would reject the kernel, since in my experience, it *is* drop-in compatible. It is important to maintain stable as stable for existing server installs, but still keep it useful for new deployments. I think we can achieve the latter without compromising the former, in a little better way that we have done to date. It's also important for desktop installations that shouldn't change every other day. Indeed. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Martin Schulze schrieb am Samstag, den 26. August 2006: *snip* That's nothing for a *stable* Debian release. However, thanks to nobse there is the backports repository which is perfectly suited for such an effort. Not sure if anybody bothered to backport Mozilla and friends yet, though. (I guess not. Hint! Hint!) Hey, thats already there: http://backports.org/debian/pool/main/f/firefox/ http://backports.org/debian/pool/main/t/thunderbird/ But please read the instructions before: http://backports.org/dokuwiki/doku.php?id=instructions Alex signature.asc Description: Digital signature
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 02:13:33AM -0500, John Goerzen wrote: On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: John Goerzen wrote: Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with only security updates. New kernel packages, and a rebuilt install image, yes. New utilities? Which utilities? The only one I'm aware of that breaks with newer kernels is udev, and hasn't that been fixed for awhile now? I've never had a problem taking a stable box and putting a nice shiny new kernel on it. Which utilities have to be updated here? I'm not talking about something like 2.4 to 2.6, just point releases within 2.6. Well, the etch preparation time saw the switch to 2.6, the devfs removal and the corresponding ramdisk generator troubles, as well as assorted udev troubles. The real problem, is that for seamless kernel upgrades, a lot of infrastructure is needed, and this has been part of my plan (or private agenda like Frans accused me of, altough there is nothing private about it, since i claimed it high and strong since over a year now, and it is done not to further my own benefit, but for the best of debian, the ease of the stable security team and stable d-i upgrades, and situation likes this. Anyway, the plan i was proposing since april 2005, shortly before the etch release, called for an unified kernel package (which we attained in a successfull way, culminating with the 2.6.14 release and its same-day upload), as well as other yet to be implemented or currently under implementation parts. It had : - a single kernel source package, building all the .debs for all arches, as well as all the .udebs for d-i. - an infrastructure for out of tree modules, either incorporating them in the same main kernel package like ubuntu has done, or a single out-of-tree package like is under way, or a set of individual such out of tree packages, but identified ones, and all using the same infrastructure. It was trying to push for this one, which would make upgrading kernels on kernel abi changes for security or upgrade issues seamless, but faced the very strong and agressive oposition of the d-i team, who is now in a situation where any changes in this respect cannot be accepted by them, for fear of losing face and having to admit that i was right, so we are thus hosed in the near future. This plan needs to be complemented by cooperation with the other kernel related tools, like udev, module-init-tools and such. With all this in place, we could do kernel and d-i upgrades in a matter of days, and it only would need tests for regressions in the kernel code itself, or in the interface of those helper tools, but given the importance of those kernels upgrades (a quick test, who really runs sarge kernels on sarge, and not some self-built or backported ones ?), it would be fairly easy to find a big enough tester set to validate those for later upgrades. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
John Goerzen wrote: On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: John Goerzen wrote: Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with only security updates. New kernel packages, and a rebuilt install image, yes. New utilities? Which utilities? I already forgot most of them again, but among the packages required were: mkinitrd kernel-package debhelper yard Just try to get a more recent kernel from backports.org on a sarge machine and you'll see. The only one I'm aware of that breaks with newer kernels is udev, and hasn't that been fixed for awhile now? Oh, right. udev as well. I prayed for the machine to boot as it was in a data center several km away from me. *sweat* I'm not talking about something like 2.4 to 2.6, just point releases within 2.6. I'm talking about 2.6.8 (sarge) to 2.6.15 (current kernel that time) It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) Well, a repo for updated ISOs would be more useful to people, I think. But again, when somebody goes to debian.org to download stable, they'll get something that doesn't work. That's something that could be done afterwards, but I agree, that updated iso images, at least for the businesscard and network installation would be great as well. It would be better to, say, issue 3.0.1 with a newer kernel package. This wouldn't even have to cause any impact at all to existing installations. As I told you already, just look at the progress to get an updated 2.6.8 inclusive installer into the 3.1 stable release. It's problematic enough already, not to speak about a new kernel version and new tools and modified installer code, and differntly behaving packages, and and and. * Infrastructure updates such as ClamAV and Spamassassin We already have this in form of the volatile archive. That's exactly what volatile is for and why it has been started. For these packages it works quite well. True, but it would be better to make it more official. Plus, are you going to stick X, PostgreSQL, and MySQL in volatile? No, but into backports.org. We're trying to get volatile more official, to be continued... * Updates must undergo testing, ideally with peer review For this we don't have the infrastructure with regards to stable, and it's also not possible to update stable just again because we noticed that Firefox creashes 50% of the time. Backports is much easier to handle for this and should be used. If this stays small-scale -- and it should -- this could be as simple as having, say, 5 trusted developers' GPG signatures on a message saying they have evaluated it against standard criteria and it passes. Doesn't have to be a massive thing. That's not sufficient when new versions of software are included that behave different, hence, break scripts, break users impression and the like. That will make Debian stable an unstable system. This is not what we should aim at. Really. But you're right, we would absolutely want to make sure we get it right. It's a hurdle, but I wouldn't call it insurmountable. Such updates should be provided as an add-on like with the backports.org archive. Then users can decide if they want to try an update and maybe become happy with it. By the way, I've been told that a more recent Firefox is already included in the backports archive. Feel free to use it. * Updates must be drop-in compatible with the released stable -- no config file incompatibilies or new debconf prompts, no new library so versions or deps on libraries not in stable, etc. This rejects packages like the kernel or Mozilla and friends already. Again, I am confused about why this would reject the kernel, since in my experience, it *is* drop-in compatible. Well... not at all. It may require a more recent udev, more recent hotplug, more recent mkinitrd, more recent $foo, old drivers that formerly worked, may not work anymore, old firmware (sorry, binary-only, non-free crap) that was used formerly may not work anymore since a newer version may be required. Devices may be named differntly even without udev (think of two SCSI adapter whose order is switched for whatever reason, this has happened already). Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 09:57:37AM +0200, Martin Schulze wrote: John Goerzen wrote: On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: John Goerzen wrote: Examples of things that should happen in stable, but haven't been happening reliably: * Kernel updates with more broad hardware support This requires new kernel packages, new utilities and a new installer. It a hell of an effort to get this done. Just look at what it takes to update these in stable with only security updates. New kernel packages, and a rebuilt install image, yes. New utilities? Which utilities? I already forgot most of them again, but among the packages required were: mkinitrd mkinitrd is dead :) kernel-package well, one could consider kernel-package as part of the kernel package, really. debhelper debhelper ??? yard yaird is its name. Just try to get a more recent kernel from backports.org on a sarge machine and you'll see. Actually, apart from the udev issue, only a recompiled yaird is needed to run the latest sid kernel on a sarge machine. I am actually typing this, on a sarge/powerpc machine, where the latest sid kernels was installed as is on a sarge system with only the rebuild yaird. Naturally, initramfs-tools and is huge dependency chain on world+dog is a fully other matter. The only one I'm aware of that breaks with newer kernels is udev, and hasn't that been fixed for awhile now? Oh, right. udev as well. I prayed for the machine to boot as it was in a data center several km away from me. *sweat* Yes, we should get a backported udev with more stability going or something. Udev is the real pain on this, and since initramfs-tools needs it ... I'm not talking about something like 2.4 to 2.6, just point releases within 2.6. I'm talking about 2.6.8 (sarge) to 2.6.15 (current kernel that time) yeah, udev sucks, but apart from that it should be transparent. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
Sven Luther wrote: mkinitrd mkinitrd is dead :) Whatever... :) debhelper debhelper ??? Didn't it creep in? Maybe not. yard yaird is its name. Oh well... Just try to get a more recent kernel from backports.org on a sarge machine and you'll see. Actually, apart from the udev issue, only a recompiled yaird is needed to run the latest sid kernel on a sarge machine. Err... you'll have to be able to compile the kernel as well or you won't be able to add security support to it, and that would be an even larger nightmare. Naturally, initramfs-tools and is huge dependency chain on world+dog is a fully other matter. Ah, maybe I meant this one instead of mkinitrd :) Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
[EMAIL PROTECTED] wrote: I am mainly interested in #1. I think we need to take a more expansive view of what constitutes a functionality problem, perhaps replacing truly critical with serious. I fully agree. I do not consider volatile a solution. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
At Sat, 26 Aug 2006 11:52:29 +0200, Michael Banck wrote: On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ And when you see my SVN repository and sources, you'll find how hard to use newer Debian kernel on current Sarge installer, John. If new kernel has perfect compatibilities with older kernel (such as using devfs and mkinitrd), updates may be easier. Even if so, I think applying new kernel will make a lot of jobs for d-i team. Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
On Sat, Aug 26, 2006 at 09:03:12PM +0900, Kenshi Muto wrote: At Sat, 26 Aug 2006 11:52:29 +0200, Michael Banck wrote: On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote: It would be good, though, especially in order to have some support for hardware that has entered the market after the last Debian release, if there would be an outside repository for updated kernel and installer packages. However, nobody considered this important enough yet. (Hint! Hint!) Kenshi MUTO provides some at http://kmuto.jp/debian/d-i/ And when you see my SVN repository and sources, you'll find how hard to use newer Debian kernel on current Sarge installer, John. If new kernel has perfect compatibilities with older kernel (such as using devfs and mkinitrd), updates may be easier. Even if so, I think applying new kernel will make a lot of jobs for d-i team. Again, maybe I'm missing something on mkinitrd, but I don't see that as such an issue. devfs, I can see that. But I'm not trying to talk in this thread about how hard or easy it is technically to build stuff for stable. That level will change over time. (And if we really find it so much more difficult to build a kernel for stable than other distros do, we need to examine that and make needed improvements. Maybe Joey Hess can comment on the installer here.) The question I'm trying to open up is first: Is it useful to update a kernel in stable? And secondly: Is it possible to do it in a sane way, preserving stability? And finally, if so, then we need to ask: How can we make it easy for everyone involved to do this? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rethinking stable updates policy
John Goerzen wrote: But I'm not trying to talk in this thread about how hard or easy it is technically to build stuff for stable. That level will change over time. (And if we really find it so much more difficult to build a kernel for stable than other distros do, we need to examine that and make needed improvements. Maybe Joey Hess can comment on the installer here.) The question I'm trying to open up is first: Is it useful to update a kernel in stable? It is probably useful to provide updated kernel pacakges and installer - but separate from Debian stable. And secondly: Is it possible to do it in a sane way, preserving stability? Good question. For sarge and = 2.6.15 I'd say no. And finally, if so, then we need to ask: How can we make it easy for everyone involved to do this? Don't change the kernel too much, don't change kernel packaging too much. While we have influence on the second, we don't have influence on the first. Regards, Joey -- Have you ever noticed that General Public Licence contains the word Pub? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Well, I hereby fully agree with Peter's expectations. And I am a DD. Please don't dismiss people just on grounds that they're not, yet, DD's. Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
