Re: Tentative Roadmap for Dada Mail

 
From: "Shane Clintberg" <shaneclintberg@PROTECTED>
In-Reply-To: Tentative Roadmap for Dada Mail
Date: August 9th 2005
 
> this is the draft of the roadmap for Dada Mail, let me know what your thoughts are
 
Well, first, some introductory thoughts to, uh, begin...
  • Thank you for this! Having these plans out in public is immensely helpful for those wishing to pitch in. (I hope you'll be putting them up on the site and/or CVS, and reviewing and revising them as necessary.)
  • Version branching definitely looks worth whatever trouble/learning curve it will bring.
  • Release 2.10 sounds nice...but personally, I'm really looking forward to 2.11. :-)
  • Sorry to hear about the support falling through for the multiple-field database work. I know a lot of people have asked about/for this...and I'm sure it's personally frustrating as well.
 
And having said all that, here's a nittier-grittier thought for us to chew on...
 
My first Dada Mail CVS commit was an overhaul of the program's default CSS template. And because it was a major, structural overhaul -- that is, not just a change of a line or two, but a shuffling of large chunks of code -- Justin found it impossible to merge his local-repository changes back into it, and ended up having to rewrite them into my version as though he was working from scratch.
 
Since then, however, our various commits to that CSS file have been pretty seamless, because a good CVS client can easily (and often automatically) handle non-structural,  "diff-friendly" revisions (such as the addition, removal, or change of a single line or consecutive lines of code).
 
My point here? Simply that if I had made those structural revisions over time, Justin would have been more likely to run into labor-intensive merging conflicts over and over again...but because I did them all in one go, we then had a common structural basis that made it easy to merge our separate repositories from that point forward.
 
I think the same type of concern will apply to versioning branches as it did and does to the files in our separate repositories. And for this reason, I think it would be extremely wise for us to review the structure of Dada Mail's various files and directories, and to make sure they're "future proofed" as much as possible, before we branch them.
 
Here's a concrete example of how this may become important:
 
Justin, you say you'd like to move the HTML error messages currently in Errors.pm into the /templates/ folder between version 2.10 and 2.11. Branching-wise? No problem.
 
And for argument's sake, let's say you want to put them all in a subdirectory, /errors/, to keep things more organized. Still no problem; we're golden.
 
But if you decide you'd also like to add subdirectories for /screens/ and /widgets/ to make things ever cleaner, and you want to move the relevant current templates into these new subdirectories, the only good time to do that would be before version 2.10 is branched...because otherwise, your changes won't merge well with the 2.10.x bug-fix branch, and we'll have to do a bunch of manual diffing & merging after the fact to get things back on the same page.
 
Does that make sense? Basically, what I'm thinking is that now that you have a roadmap, I think it would be a good idea to imagine how you want the program to be organized in the long term, and then to make those structural changes, if any, now rather than (more painfully) later.
 
This sort of "future-proofing" might apply to three areas:
 
1) file locations within the overall directory structure
(as per the example above)
 
2) directory names
(e.g.: Considering its content, might you ever want or need dada/DADA/Template/ to be renamed dada/DADA/Web/ ?)
 
3) file names
(e.g.: Will we ever want or need the control panel-specific CSS put into its own file? If so, default_css.css should be renamed default_global_css.css .)
 
 
Yes, I recognize that even pre-branching, any and all of this restructuring would be a pain...which is why I don't think we should do it unless we have to.
 
All I'm saying is that you should think about whether you know we ever will have to...and if the answer is yes, we should do it now and save ourselves the extra branch-merging problems later.
 
 
Sorry for being so wordy; as usual, I'm writing this at a strange time of night. I hope at least some of this makes sense. :-)
 
_s.
 
 

Post:
mailto:dadadev@PROTECTED

Unsubscribe:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/u/dadadev/

List Information:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/dadadev

Archive:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/dadadev

 
rss/atom
‹ Re: Tentative Roadmap for Dada Mail (changes)
Index
Re: Tentative Roadmap for Dada Mail ›
  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)

  • Start a new thread, email: dadadev@dadamailproject.com

This is the developer discussion mailing list for Dada Mail.

If you are just looking for support Dada Mail, consult the message boards at:

https://forum.dadamailproject.com

Documentation for Dada Mail:

https://dadamailproject.com/d

Specifically, see the Error FAQ:

https://dadamailproject.com/d/FAQ-errors.pod.html

To post to this list, send a message to:

mailto:dadadev@dadamailproject.com

All subscribers of this list may post to the list itself.

Topics that are welcome:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

Dada Mail is on Github:

https://github.com/justingit/dada-mail/

If you would like to fork, branch, send over PRs, open up issues, etc.

Privacy Policy:

This Privacy Policy is for this mailing list, and this mailing list only.

Email addresses collection through this mailing list are used explicitly to work within this email discussion list.

We only collect email addresses through our Closed-Loop Opt-In system.

We don't use your email address for any other purpose.

We won't be sharing your email address with any other entity.

Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.

All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.

All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.