Re: [Dovecot] 1.0.rc29 released
On Fri 30 Mar 2007 at 06:07PM, Timo Sirainen wrote: http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig Probably one more RC after this. Hey all-- for those interested in deploying 1.0rc29, I just wanted to report that I deployed 1.0.rc29 Monday evening and it has been absolutely rock solid for the past 48 hours: zero core dumps, and I have fielded no significant complaints in the past two days. At this moment we have 220+ processes in our dovecot deployment serving 103 users. We did a little measurement and it's nice to see that dovecot is very resource efficient; here is an aggregated view of all of the dovecot processes we are using: PROJIDNPROC SWAP RSS MEMORY TIME CPU PROJECT 100 221 179M 196M 0.6% 2:22:24 0.2% imap So my runtime RSS per User is about 2MB. Wow. (In recent Nevada builds we've refined prstat's ability to correctly measure RSS for projects, zones, etc. so this number should be pretty accurate). We're still working on debugging why our Kerberos setup isn't working-- Thanks to Timo we have auth_gssapi_hostname, but we're still not quite there... our Kerberos engineers are looking into it. I've gotten a lot of compliments about how stable and fast our setup is compared with the old deployment-- those really should go to Timo. Thanks! -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
Re: [Dovecot] 1.0.rc29 released
On April 4, 2007 6:35:27 PM -0700 Dan Price [EMAIL PROTECTED] wrote: We're still working on debugging why our Kerberos setup isn't working-- Thanks to Timo we have auth_gssapi_hostname, but we're still not quite there... our Kerberos engineers are looking into it. There was a recent thread on heimdal-discuss talking about load balancing. (The issue with mismatched hostname is the same.) One person discussed how they fixed dovecot to work in their setup. It involved (IIRC) passing GSS_C_NO_CREDENTIAL to gss_accept_sec_context(). Maybe that thread will help you out. -frank
Re: [Dovecot] 1.0.rc29 released
--On Saturday, March 31, 2007 9:32 AM +0200 John and Catherine Allen [EMAIL PROTECTED] wrote: - mind share in the boardroom is not the only possible goal for a project I was thinking of installed base, not commercial users per se.
Re: [Dovecot] 1.0.rc29 released
On Saturday March 31, 2007 at 08:32:40 (AM) Jeff A. Earickson wrote: My one concern about dovecot is the feeping creaturism in the code. Why does it have to be an LDA? That is what procmail is for. And designing your own mailbox format (dbox?) seems dangerous too. I would have it stick to POP and IMAP, period. But then it is not my code either. It works great for IMAP, which is what I need. Personally, I like the LDA feature in Dovecot. Procmail is a memory hog with a cavorted rules configuration scheme. Its use has seriously declined in favor of better products now available. Procmail is best left to single user status. I would never consider employing it in a multi user environment, although I know it has been done. Why though I fail to understand. There are better and easier methods available. There is no inherent danger in designing your own inbox structure, provided that no other application attempts to access it incorrectly. Dovecot would not be the first LDA/POP/IMAP application to do this. -- Gerard A psychiatrist is a man who goes to a strip club and watches the audience. Merv Stockwood
Re: [Dovecot] 1.0.rc29 released
Dean Brooks [EMAIL PROTECTED] writes: I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. At the end of the day, the question is how to call it - if it's alpha, beta, rc, all have different needs. Yes, it should have been alpha or beta. OTOH, if you've tried to get people to test release candidates, that is hard enough. Most will silently wait for the real release ship when they next update their $DISTRIBUTION (and after that complain that from 0.99 to 1.0 the configuration file format changed, or something like that). So I still have some sympathy for Timo's many release candidates. I'd rather he called a broken release RC rather than have showstoppers in the actual release :-) Features aren't good in rc though. But let's wait how 1.0 looks before we complain :-) -- Matthias Andree
Re: [Dovecot] 1.0.rc29 released
At 8:32 AM -0400 3/31/07, Jeff A. Earickson wrote: On Fri, 30 Mar 2007, Frank Cusack wrote: FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me. 1.0 = shit is almost always true for payware IMHO. Open source has a far better track record on this. If I had to give dovecot a version number right now, I would say it is about version 9.8. My one concern about dovecot is the feeping creaturism in the code. Why does it have to be an LDA? That is what procmail is for. That specific case is a very good thing. Procmail is not a good piece of software to rely on and offer to users as their filtering tool. -- Bill Cole [EMAIL PROTECTED]
[Dovecot] 1.0.rc29 released
http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig Probably one more RC after this. * Security fix: If zlib plugin was loaded, it was possible to open gzipped mbox files outside the user's mail directory. + Added auth_gssapi_hostname setting. - IMAP: LIST didn't return anything if there didn't exist a namespace with empty prefix. This broke some clients. - If Dovecot is tried to be started when it's already running, don't delete existing auth sockets and break the running Dovecot - If deliver failed too early it still returned exit code 89 instead of EX_TEMPFAIL. - deliver: INBOX fallbacking with -n parameter wasn't working. - passdb passwd and shadow couldn't be used as master or deny databases - IDLE: inotify didn't notice changes in mbox file - If index file directory couldn't be created, disable indexes instead of failing to open the mailbox. - Several other minor fixes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 1.0.rc29 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timo Sirainen schrieb: http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig Probably one more RC after this. * Security fix: If zlib plugin was loaded, it was possible to open gzipped mbox files outside the user's mail directory. + Added auth_gssapi_hostname setting. - IMAP: LIST didn't return anything if there didn't exist a namespace with empty prefix. This broke some clients. - If Dovecot is tried to be started when it's already running, don't delete existing auth sockets and break the running Dovecot - If deliver failed too early it still returned exit code 89 instead of EX_TEMPFAIL. - deliver: INBOX fallbacking with -n parameter wasn't working. - passdb passwd and shadow couldn't be used as master or deny databases - IDLE: inotify didn't notice changes in mbox file - If index file directory couldn't be created, disable indexes instead of failing to open the mailbox. - Several other minor fixes HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g - -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGDTESfGH2AvR16oERAkisAJ45K6MnCCR2XTSdEA7HUef2ihdA0wCeLpJz XE+W4N94pM5vjpbXosgHiHY= =oitS -END PGP SIGNATURE-
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote: HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. Geert pgpsI2rExOMQR.pgp Description: PGP signature
Re: [Dovecot] 1.0.rc29 released
Le 30.03.2007 18:23, Geert Hendrickx a écrit : On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote: HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. Changes will be certainly minimal after v1.0 final release, you can't blame Timo for trying to make something more and more usable and adapted to everybody's needs while v1.0 is still in development.. -- Nico Rien ne m'est sûr que la chose incertaine. -+- François Villon (1431-1463?), Ballade du concours de Blois (vers 9) -+-
Re: [Dovecot] 1.0.rc29 released
Geert Hendrickx wrote: What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. What part of Release Candidate isn't clear here... ;-) Seriously, until 1.0-final comes out, everything is up for grabs; though one would hope that the number of changes per RC is going to approach zero at some point... ;-) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 12:35:09PM -0400, John Peacock wrote: What part of Release Candidate isn't clear here... ;-) release candidate equals latest supported release in this case as well. If they were 2.0 rc's, I'd continue running the latest 1.whatever release until done. Geert
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 07:35:40PM +0300, Timo Sirainen wrote: I hate how badly the configuration file updating works everywhere (well, or at least in Debian). If the changes don't really change any existing settings and won't conflict with the modified parts of the config file, there's no need to ask anything about merging. Why couldn't it work by doing a diff of the old and new default config files, and then try to patch the changes into the current config. If the patch succeeds, that's your new config. Of course if the new config file really changes existing defaults, it shouldn't do this without asking. I'm actually doing a merge dovecot.conf old-default new-default every time, and it usually causes some conflicts due to changed comments. They're easy to resolve, of course, but it could be avoided. Geert pgpcP3Q3sMDjc.pgp Description: PGP signature
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. [snip] So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 4:05:55 PM -0700 Kenneth Porter [EMAIL PROTECTED] wrote: --On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other. They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well. In principle, a release candidate should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers. Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break? Will 1.0 be stable enough to replace 0.99? You are going to have to do the exact same testing from 0.99-1.0 as you would from 0.99-1.0rc29. Caveat emptor with open source software; the responsibility is upon YOU to do your own testing. It sounds to me like the reason you are running 0.99 is not because of any rc naming and/or lack of stability, it is because Fedora ships with 0.99. So you should just wait until Fedora updates it and not worry about the fact that the rc releases are misnamed. So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. People ARE getting experience with the rc's. That's why there's so many of them: feedback. Why do you care anyway? (Not attacking you.) If 0.99 works for you, great! -frank
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 7:31:15 PM -0400 Dean Brooks [EMAIL PROTECTED] wrote: On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. [snip] So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. ??? 1. write code 2. release for testing 3. incorporate feedback Doesn't seem that unusual. It's just that rc is misnamed. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. Sure, Timo probably did screw up by wanting 1.0 to be so great and all, and not just freezing things where they stood, but who cares? Just stick with 0.99 or 1.0beta8. It's great that he releases so many rc versions and so many people test them and shake out bugs. I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) Seriously though, if you so desperately want dovecot frozen somewhere, use 1.0beta8 or 1.0rc1 and pretend it was released as 1.0. -frank
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 4:41 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: You are going to have to do the exact same testing from 0.99-1.0 as you would from 0.99-1.0rc29. Caveat emptor with open source software; the responsibility is upon YOU to do your own testing. Actually, no. A few people keep up with the latest rc's. A lot of people will install 1.0. I try never to be the first lemming over the cliff. I wait to hear the sounds of the others splash, to see where the rocks are. With a proper 1.0 release, I can have high confidence in knowing what bugs to expect before I install it. I don't have that confidence with an rc tried by only a handful and then rapidly replaced with its successor. Windows Server 2003 Service Pack 2 came out a week ago. I'm leaving it in the unapproved queue for a couple weeks, maybe a month, to hear what happens to the early adopters. I'm quite sure it will have its share of problems, and I can live with that, as long as I have some idea of what they are. Note that I'm a small shop. I don't have the luxury of a parallel testing environment like some corporation with hundreds or thousands of employees and the IT budget to match. I rely on the experiences of other admins with the deep pockets to do that sort of thing. It sounds to me like the reason you are running 0.99 is not because of any rc naming and/or lack of stability, it is because Fedora ships with 0.99. So you should just wait until Fedora updates it and not worry about the fact that the rc releases are misnamed. It's because lots of people are running this version, and it's a known entity. Why do you care anyway? (Not attacking you.) If 0.99 works for you, great! Because there are features in 1.0 I'd like to start using. But I don't want to have to wait for tomorrow's feature's testing before I can use yesterday's features. Lock down 1.0 and ship it. Most people realize that a dot-oh release is going to have bugs. Let the wider community start getting experience with it. Don't do any more coding on this branch except bug fixes.
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. Once 1.0 locks down, you should see a huge expansion of users. Bug fixes (not features!) in 1.0.1 will see further expansion. Any new features (like the recent addition of the wiki to the tarball) should be in the scary and experimental 1.1, not 1.0.
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 5:04:58 PM -0700 Kenneth Porter [EMAIL PROTECTED] wrote: --On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. Once 1.0 locks down, you should see a huge expansion of users. Please don't mistake my email for any involvement with dovecot development. AFAIK, Timo is the one and only developer. That's sure to win over your board and boards worldwide. FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me. -frank
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 5:22 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: Please don't mistake my email for any involvement with dovecot development. AFAIK, Timo is the one and only developer. That's sure to win over your board and boards worldwide. If you mean a single developer might scare away users, I don't think that's the case. Plenty of popular software is developed by a single person or a very small developer group. And with open source, the loss of the developer doesn't mean that the application gets orphaned. FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me. My concern is not quality but predictability. There's a reason 0.99 and 1.0 software is poor quality: Few people are willing to risk using it, so it doesn't receive widespread testing. More will use 1.0 than 0.99, and more yet 1.0.1. The rc on the end of the current dovecot is little better than 0.99 to those who insist on a 1.0. (It's psychologically better, but only just marginally better.) I also don't seek more users out of some kind of popularity vote. I'm looking for the many eyes effect. With more people using it, more issues get identified. It's like sending an army of bots over a minefield, so I don't have to be the one losing a leg.
Re: [Dovecot] 1.0.rc29 released
Quoting Dean Brooks [EMAIL PROTECTED]: I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. I've seen about the same from other pre-1.0 software projects. The usual problem (and I have no idea if this describes Timo accurately or not, though it appears as such to me), is that the people (usually one person) heading the project are not experienced with large-scale software releases, and they make some simple mistakes. Often they look back years later and reflect on how they were in over their heads when they started, etc. But, let me also say, that in the above paragraph I am thinking of 3 projects, all of which I use in production, all of which I love, all of which have worked out their problems after their first major release. I would say, in general, these types of things are just growing pains and shouldn't be too surprising to most people. What would be surprising (and bad) was if they continued through the following releases. Timo has already admitted his errors on the mailing list recently, and has already sought advice on how to fix them in the future, so I would think the future is bright for dovecot. And eventually, we'll all forget the past... There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. Actually, that is more due to the large number of RC cuts Timo makes, rather than the number of bugs in the code, IMHO. I've found several of the releases to be very stable for me, as have others. Of course, I'm very selective as to which I install and test; I don't test each RC that comes out (in particular, since I run mbox, I don't run ones that have only maildir fixes, etc). I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. I believe Timo already has done so, based on his comments on the list, and his requests for help on things like versioning systems, test suites, etc. If you've been reading the list over the last couple months, I think you would recognize this. But then, I don't speak for Timo. -- Dean Brooks [EMAIL PROTECTED] -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
Re: [Dovecot] 1.0.rc29 released
Quoting Kenneth Porter [EMAIL PROTECTED]: That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. While, is there really no one between the boardroom and the avant garde hobbyists? I didn't realize there was such a void between those levels... Once 1.0 locks down, you should see a huge expansion of users. Bug Yes, well, of course. We all know that already. fixes (not features!) in 1.0.1 will see further expansion. Any new features (like the recent addition of the wiki to the tarball) should be in the scary and experimental 1.1, not 1.0. That is simply documentation, not really a feature. And it is actually fairly normal to add and refine documentation during a RC release. I agree in general with the no more features requests, but docs are really a whole different thing. Most shops are working on the docs right up to the last minute for every release. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
Re: [Dovecot] 1.0.rc29 released
On 2007 Mar 30 (Fri) at 20:56:43 -0700 (-0700), Kenneth Porter wrote: :--On Friday, March 30, 2007 8:26 PM -0700 Peter Hessler :[EMAIL PROTECTED] wrote: : :This sort of decision is exactly why I'm the mail admin and they are :not. They know things at the boardroom level, and they are :(presumably) good at it. I don't look at things from the boardroom :level. However, I understand the MTA-related arena better than they do. :If they understood the details, why would they spend the money on my :salary. : :So which rc are you running in production? What made you decide that rc and :not some other was good enough without being too risky. What's your :confidence in that particular rc? : :I'm looking at 29 rc's and I have no idea how to pick. What's your method? I personally am running rc22, and plan on upgrading to rc29 this weekend. I chose it because it was the most recent dovecot when I last upgraded. I've previously been upgrading to each rc within a day or two of release. My upgrade testing goes like this: Install it on a non-mailserver box, setup a bogus mail directory (usually a cp of my regular Maildir/), poke at it with ipv4/ipv6 over both imap and pop3. Usually 20 minutes is enough to figure its quality. If it passes, then I kill the master dovecot process, uninstall old, install new, start up, run tests again. -- Don't take life so serious, son, it ain't nohow permanent. -- Walt Kelly
Re: [Dovecot] 1.0.rc29 released
On Fri, 2007-03-30 at 16:05 -0700, Kenneth Porter wrote: --On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other. They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well. In principle, a release candidate should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers. Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break? It is stable enough. I've been using it in production, and each RC, with no issues. Really damn good software. 1.0.rc1 was released in June. Here's a quote from the release message for rc11 (November 4): Hopefully the last RC release? As far as I know there are no major problems left now. If nothing big shows up, v1.0 should be out in a couple of weeks. In rc27: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. Oddly, the new features don't seem to act up. Just little issues keep coming up.