Okay, it's a new year, well 3 months into it. What do you think we can do
to improve? If you have references to your old ideas, that'd be great.
We are always looking to improve things. We are currently working on a
new website, bug tracker, and documentation to name just a few things, so
we are certainly interested in feedback on what we can improve on.
Do not only maintain CVS. Offer us a stable base version AND bug fixes. Accept
users input (like code pieces) in a forum. Use this code as an inspriration
for SM enhancements. Use my site as an inspiration :-).
I understand your idea, and I agree with some of your points. I
understand why you're doing it, but I always hate it when this happens
to open source projects: updates, patches, fixes are offered on "other
sites". A lot of people might not know of them, or benefit from them, or
understand why and where this comes from.
Off-topic: I think it's something not only related to squirrelmail, but
generally a "problem" of (distributed) open-source development; I've
seen other open-source projects suffer of this- development delayed by
guidelines that are too strict, that keep people from either
contributing or getting CVS access (or maybe they simply don't know
CVS). One example of this is the drupal CMS (http://www.drupal.org/).
I'd rather see a "unofficial" section (maybe a forum?) or upload area on
squirrelmail.org. Marked as "unofficial", or some other more appropriate
text, meaning that people will recognize it as patches that might not be
endorsed by the squirrelmail team or the plugin developer, for whatever
reason. I think that would be fine.
Having said that, you know, I don't know your code, and maybe the plugin
developers or development team had reasons to turn patches or fixes
down. Maybe there is concern about "quick and dirty" hacks that will
only work for some people or break other functionality? There are always
the two sides of the coin.
Take one moment to think ybout this: After installing SM 1.4.6 and installing
a couple of plugins, I'd to apply 16 patches to get SM into a stable
productive version. The plugins installed are only those desperately requested
the the SM users. Additionally I'd to apply 9 translation patches because of
the poor internationalization support in those plugins (and I hope, the users
will never ask for other translations than into German...)
Yes, this is true, and it makes me somewhat reluctant to upgrade. Right
now, I have an issue with sqmail 1.4.4 and i18n not working, but I need
webmail working in Thai. So I have to upgrade to 1.4.6 where it's
working, I've already tested that.
I have a total of 37 plugins installed. A lot of them require you to
patch the squirrelmail code, and patches depend on squirrelmail version.
This is really, really, ... REALLY painful.
sqmail would benefit from a plugin installation procedure that keeps
track of patches one needs to apply to the sqmail source. this could be
done automatically. it could also keep track of which patches have been
applied. On an upgrade of squirrelmail, patches could be reversed and
re-applied. or something like that.
Bad approach. It was stopped immediatly with a NO-GO. No chance to modify any
existing plugin until the current maintainer dies or a SM developper (whoever)
think someone else should take over the plugin maintenance. Since I only
wanted to apply bug fixes and not to take over responsibility, I'd no choice.
I stopped this approach and started working on SM Patch Forum...
I think you mean well, but it is really hard to navigate your site.
Almost as painful for me as you said it is to look and search through
sourceforge. If you want a patch forum, I think it should be a site
dedicated to only that, not containing other content as well. It should
also be possible to simply have listing of all plugins, by category, by
clicking on a link. or some such thing.
but I'd like to see all that on squirrelmail.org anyway, under a new
section.
[..]
duplication, in my opinion, is a waste. If patches, fixes, and such are
all kept in one location, that's great. That might be something worth
considering for the new SM site (not to steel your idea of course).
yes please ...
In general, it only makes it easier for us (you, me, Paul, etc) in general
as we can say "click here". My comment was that people aren't going to
bother looking at a patch site, and waste their time, when they can send a
quick email, and have somebody else give them the answers. Unfortunately
that's the way it is. Always has been, and probably always will be.
it doesn't have to be that way if you find another solution, e.g.
incorporate some such thing as an "unofficial" patch repository on the
official sqmail site.
This is a bit in contrast to my previous mail, but as with many things
it's about the "how" you do it part. An "unofficial" patch repository
(and I don't mean CVS) would be a benefit. Having stuff like that
off-site is detrimental. It "forks" some development, and not all users
will know about it.
Johannes
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
--
squirrelmail-users mailing list
Posting Guidelines:
http://www.squirrelmail.org/wiki/MailingListPostingGuidelines
List Address: [email protected]
List Archives:
http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
