ok hi, first, I'd like to explain our 'TODO' mail system.. it's a system
we've been using for previous releases and since some of you are new to the
team, you might not know how it works...
It's simple, we give a list of TODO items by mail, when you want to add or
remove an item, you simply write :
ADDED :
- do this
or
REMOVED:
- this bug
(can't remember we wrote REMOVED or DONE.. either way is fine, although it
might be better to differenciate both as one bug is fixed versus one bug has
been dumped cause it can't be fixed, or invalid, etc...)
You can also write a comment with your todo item, like explain why adding
it, or why removed it, etc...
and THEN, the important part, is that you must copy/paste the TODO from the
previous mail (no ">" in front of it or anything), and add/remove your todo
items to it.. and that's it.. the rest of the mail should be cleared of any
extra info...
I'll give an example in a few seconds...
KaKaRoTo
On Wed, Jan 28, 2009 at 11:12 AM, Mirko Hansen <baaa...@gmail.com> wrote:
> 2009/1/28 Vivia Nikolaidou <vi...@ee.auth.gr>
>
>> 2. Proposal concerning the auto update function: Shouldn't we extend the
>>> auto update to be able to update files of the core? (Not for major releases,
>>> only for minor updates!) I think it would be a good thing as there are many
>>> protocol changes recently and it would help to fix minor bugs a lot faster
>>> because we are able to spread single core files instead of having to create
>>> a complete release that takes a lot of time. What do you think?
>>>
>>
>> It's a good thought in theory, but in fact there might be many more
>> changes reflected to other files as well. For example, imagine adding an
>> extra argument to a proc on protocol.tcl and the respective change on
>> gui.tcl regarding the way it's called. Then we distribute protocol.tcl
>> because of a later protocol change and suddenly the "stable" revision bugs.
>> We'd need to distribute the patch instead, or think of a smarter way to do
>> it.
>>
>> It's a good idea however, and if someone can think of a better way to do
>> it, it would be nice to include it in 0.98.
>>
>
> In theory we could only deliver patches and add a binary of "patch" to the
> package for those OS that don't have patch in their repository by default.
> That would be the perfect way to distribute the patches.
> But my original idea was to keep on merging the changes in SVN from trunk
> to the branch of the release, and there make all the modified files, since
> the release, available for the auto updater. Maybe compressing them in one
> file would be better to keep the load of the server and the traffic low, but
> I think there shouldn't be any problems as long as we pay the same attention
> on what updates we offer for autoupdate as we do for a normal release.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
