Minimal version of Mail::Mailer

[Vlad Dascalu]

Hello Shane,

>You can prefer whichever you want. The fact remains that your proposed
>solution hasn't even been discussed, much less designed, coded, reviewed, or
>added to the trunk. However you slice it, an elegant, long-term solution is
>a long way off, and people are having problems *now*.
>
They don't have any problems whatsoever regarding the Perl Mail module 
specifically. At least I haven't heard of them.

Like Dave said, they are having problem with the install system. Moving 
a dependency version up and down will not solve that problem.

>Again I say; If you want to spend your time and energy developing a long
>term solution, by all means do so. Nobody is trying to tell you how to spend
>your time; by the same token, it is not your responsibility to tell others
>how to spend theirs. Your priorities are not everyone else's priorities.
>  
>
I suggested in the previous email that we should analyse what are the 
ideal priorities. Instead of having a developer spend $10 on the tree 
solution and another one on the forrest solution, I thought that it 
would be more productive to join the efforts, to do a little bit of 
design and thinking before jumping out in the water and to implement the 
optimum solution with the least bit of effort.

>>... if you have the ability to
>>estimate correctly the difficulty of the problem, you will end up with
>>the right choice and get to the results in optimum time...
>>    
>>
>
>There may indeed be an 'optimum solution' for the codebase, and if it's
>still pristine and sterile and only exists on development computers, then
>you can do whatever you want to it without affecting anyone. Once it's
>released to the public, however, the users can't just be ignored; they have
>to be taken into account.
>
>Helping the people who are actually using Bugzilla right now is *not* the
>waste of time you imply -- or, rather, outright state -- that it is.
>  
>
Nobody argues that. The issue is "how". I don't think spending 1 month 
back and forth upon a Perl module version is going to help the users. I 
do think spending that time upon the installation process is way more 
productive.

>As for 'money spent', aka 'developer time'... I don't labour under the
>delusion that I know the One True Way to get to any destination, or even if
>I did that everyone else has to listen to me.
>
Neither did I. However what I tried to say is that there might be some 
merit into doing this thing collectively, that is: analyse the problem, 
design a solution and implement it before jumping in the water. That 
opposed to the code-and-fix development.

>This is *volunteer work*. People contribute what they want, in areas where
>they are interested. If you are interested in 'the big picture', go for it!
>I'm certainly not going to tell you that you shouldn't be doing that, or
>that you've "lost touch" with individual users because you're concentrating
>on the beauty of the code and not the people who have to use it right now.
>It's your time, and your decision on how to spend it.
>  
>
Anybody has those liberties. They are implied via MPL.

The Mozilla project doesn't deal with that specifically. We, here, are 
integrators. We take those contributions from others and we provide the 
infrastructure and the logistics for that to be integrated into one 
final product that should be delivered to the user. What we're 
discussing is how to take those contributions individually and how to 
put them into the final product. Taking tree versus forrest like 
decisions affects the complexity of the system, the entry-point of 
knowledge required to enter as a developer into the community, etc. 
Taking what's on the table doesn't always work when doing that.

>>So you should respect the decisions of the community where you choose to
>>belong, but you should listen to everybody with an equal voice
>>    
>>
>
>Not everyone deserves to have an equal say in all
>things
>
I agree.

>; not everyone should be listened to equally on all topics.
>
I disagree. Apparently we're using "listening" and "respecting" here in 
different contexts.

> Some
>people have more wisdom, more experience, and more insight
>
I agree.

>It's fine to listen to everyone, but not everyone is saying things of equal
>worth.
>  
>
I also agree.

>I think it's productive to give feedback too... but that's not what you did
>in this situation. You said that Frederic -- specifically him, specifically
>for these actions -- was wrong, had lost the big picture, and was wasting
>other people's time by 'implicating' them and asking for input. Perhaps you
>*meant* it as feedback of the group as a whole, but it came across very
>strongly as criticism of one individual and the way he had decided to spend
>his time.
>  
>
Maybe it came to you that way. I've never bolded any words with 
asterisks like you do. Using this practice makes it look like you're 
screaming, and it comes as very disturbing to me. However, that's only 
my interpretation; it's subjective, so I ignore it and don't mention it, 
and focus on the non-emotional content instead.

The non-emotional debate here is the fact whether if we should encourage 
people to act together as a team in order to review together the 
existing problems and to implement an optimum solution together, or we 
should failback to the "you can't control volunteers so don't bother" 
fail-back plan. If you look at successful projects, you'll see that 
there is a lot of process in planning, making roadmaps, coordonating, 
etc, so I think that makes sense.

But we're having different perspective on this. And it seems you can't 
have a rationale discussion about things without accusing the things 
done, without marking those with asterisks in order to be more bold for 
the reader. I appreciate your contributions and your checkins :-), but 
if you keep it up in this way you'll only drive more people away, and 
due to your human nature you won't be able to scale up to those to cover 
up for the losses.

Vlad.


>Shane Travis            | My mother used to say, "In this world, Elwood,
>travis at sedsystems.ca    |  you must be oh-so-smart, or oh-so-pleasant."
>Saskatoon, Saskatchewan |  For years I was smart; I recommend pleasant.
>                        |       -- Jimmy Stewart, _Harvey_
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@bugzilla.org>
>
>
>  
>