Re: [Mantisbt-dev] Next release?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Julian,

Thanks for the info.  To be honest, when I sat down to work on Mantis, I started to do an
installer, then I was asked to workout a way to make the Reproducibility, Severity, etc, etc, etc,
fields customizable for my company, and then I got kludged on multi-language stuff.  Maybe I
should checkout the latest CVS to see if 'customizing' it easier than the current version.

Is an installer (similar to the PostNuke installer) something that the Mantis project would be
interested in?

Thanks,
Chris Shaffer

--- Julian Fitzell <ju...@be...> wrote:
> He he... we've been really close for a really long time. I started doing 
> a lot of work months ago but everyone else got busy.  And now even I'm 
> getting busy so it's been a bit of a slog, and we do aplogize for that.
> 
> We are secretly hoping to get some kind of a release candidate out the 
> door in early February, but we just keep slipping deadlines so don't 
> hold us to it.  The basic problems are this:
> 
> 1) We've introduced a ton of new APIs to make the code cleaner, more 
> consistent, and more reusable.  Only about 2/3 of the files have been 
> cleaned up to use these new APIs and I'm uncomfortable releasing a new 
> major release that isn't at least consistent in that respect.
> 
> 2) We have several other changes we want to make, such as doing a sweep 
> of all config variable names and renaming them to be more logically 
> grouped, etc.  We realize this could be a big inconvenience for people 
> so we'd really like to get it done in the next release when there are a 
> bunch of other changes happening anyway.
> 
> 3) We have so many new features.  We have major ones like new APIs, new 
> error handling, no longer needing register_globals, etc.  We also have 
> so many fixes and little features in CVS that we *really* need to make a 
> release and have needed to for a long time.  But we've also got so many 
> new features, and so many files and functions have been moved around, 
> that whatever release we make is going to have to pretty heavily tested. 
>   Now I have no problem making that release and asking people to test 
> it, but it's not going to be guaranteed to be bug free as soon as we 
> release it.  I mean literally We'll probably have *touched* every line 
> in every file since the last release.
> 
> So I don't know, in retrospect, maybe we went about this the wrong way. 
>   We should have released the new CVS code before doing the API rewrite. 
>   But it needed to be done really badly and we didn't think it would end 
> up taking this long.  I think when you see the new code you'll be glad :)
> 
> In the meantime, CVS should be totally useable. While I wouldn't 
> recommend people move to it for deployment, for anyone who wants to get 
> a head start on the testing and evaluation of the new version, or who 
> wants to jump in and fix bugs or update documentation now would be a 
> *great* time to start doing so.
> 
> If we got a bunch of people testing and reporting bugs (and I do mean 
> _bugs_ *not* feature requests :) ) that would help a lot.  And if anyone 
> wants to tackle a little feature (I know I said I'd figure out a list of 
> small tasks, but I'll do it after the release) a few that could be taken 
> on by someone are:
> 
> * provide a script to upgrade users' config files
>    - not sure what form this would take exactly, so we might
>      need to discuss it. We've renamed files and a bunch of config
>      options.  I'm not even sure we *need* it but we would if we get
>      to the complete sweep of renaming.
> * update doc/CUSTOMIZATION
>    - this may not be easy for someone unless they are already familiar
>      with how we've been changing the APIs but even just figuring out
>      what is out of date might be useful.  And it would be a good way
>      for someone to *learn* about the API changes we've been making :)
> * rewrite build_bcc_list()
>    - if nothing else, make sure it doesn't send email to developers
>      on EVERY CHANGE!!!  (not sure when that started happening)
> * try to reduce redundancy between simple and advanced pages
>    - with all the SQL pulled out, we may be able to just remove simple,
>      and check the user's pref 5 or so times before displaying the
>      appropriate sections
> * add an Acknowledge and/or Confirm button to the bug_view pages
>    - same way as we have Assign to me button
> * figure out how to phase out CRYPT_FULL_SALT
>    - our salting was all messed up.  The salt should *always*
>      be generated randomly and the encrypted password needs to be
>      given when comparing.  We've fixed the code but have two
>      problems:
>      + we need to get rid of CRYPT_FULL_SALT or support it for backwards
>        compatibility for a while, and tell people to stop using it
>      + we may need to deal with the problem that we need to regenerate
>        people's passwords.  At the moment, people using either CRYPT
>        methods have the first 1 or 2 characters of the users' passwords
>        listed in plaintext at the beginning of their encrypted forms (as
>        the salt).  I was thinking of a config option, that when enabled,
>        would re-encrypt a user's password when they login (when you
>        actually have the plaintext).  We might also want an way to allow
>        an administrator to reset all passwords to autogenerated ones and
>        send out emails to everyone - it's a bit extreme but some might
>        want it.  The first feature, could also be used to have an old
>        method and a new method so you could transition from, say, CRYPT
>        to MD5 gradually (in fact, we could just implement that - users
>        who want to fix their CRYPT passwords can just move to MD5?)
> 
>      Anyway, we can discuss this more on list if anyone tackles it
> * ZipKid reports warnings about call-time pass-by-reference being
>    deprecated in the filter_get_bug_rows() call in view_all_bug_page.php.
>    What we don't know is whether there is a solution that works without
>    warnings in 4.0.4 up to 4.3.  That function was taking optional
>    so we may need to think about how it should work (you can't make
>    parameters by reference optional)
> * remove g_php config option?
>    - We actually need to discuss this on the list.  My theory is that we
>      hardly ever use it in the code and it just makes the code uglier. We
>      don't support PHP3 so we don't really need it anyway. Anyone who
>      wants to change the file extensions that badly know how to do a
>      search and replace for '.php'.  Does anyone disagree?
> * either remove the show_source stuff or make it only work within the
>    mantis installation.  Even though you need to be an admin to run this
>    file, it still feels like a big hole waiting to happen.  At very least
>    we should restrict this file to loading files within the mantis
>    installation (like just append the path onto the mantis path, maybe).
>    Personally, I think we should get rid of it.  It is of pretty limited
>    use if you ask me.  But again, I'd like other opinions.
> 
> 
> So there you go.  If you have time to help out, just drop a line so we 
> know what you're working on and can make sure you're going the right way 
> with the patch.  I'll happily review patches to fix these or other small 
> bugs.  I'll probably defer looking at patches for new functionality 
> until after the release.  If you are submitting a patch, it would be 
> really helpful if you could submit a detailed log message showing what 
> you changed in each file (look at the commit log emails for examples) 
> and could also include changes to the doc/ChangeLog file (follow the 
> formatting in there) so that I don't have to do that myself while 
> applying it.
> 
> Hope that answers your questions! :)  And again, feel free to check out 
> CVS.  It should always work, at least mostly.  And we can be found here 
> or on IRC if you have any questions (since the docs aren't up to date yet).
> 
> Julian
> 
> Christopher Shaffer wrote:
> > When is the next release of Mantis scheduled?  If not one scheduled, about how close is the
> > project to a new release?
> > 
> > thanks,
> > 
> > chris
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
> > is essential in establishing user confidence by providing assurance of 
> > authenticity and code integrity. Download our Free Code Signing guide:
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
> > _______________________________________________
> > Mantisbt-dev mailing list
> > Man...@li...
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> 
> 
> -- 
> ju...@be...
> Beta4 Productions (http://www.beta4.com)
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
> is essential in establishing user confidence by providing assurance of 
> authenticity and code integrity. Download our Free Code Signing guide:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
> _______________________________________________
> Mantisbt-dev mailing list
> Man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com