On Tue, 13 Dec 2005 20:58:47 -0500, Karol Krizka <[EMAIL PROTECTED]> wrote:
On Monday 12 December 2005 21:57, Youness Alaoui wrote:ok, ok everyone, relax... I already said in a previous email that I had aplan to organize all this and that it would be (partially) based on the system we use at my job.. with the difference that it would take into consideration that it is no professional product and we do this in our free time... My idea is to have three more teams actually : 1 - general administration 2 - QA (Quality of Assurance.. basically testers with professional behavior and tasks) 3 - Documentation + a global 'RnD' team, which would consist of the teams listed below...I would like to set up a system for the work to be done, once a design iscomleted we'll have hunderds of tasks, and I'll probably create a sample code for everyone to start with (the interface of each class at least aswell as documented API within the code) now.. you have a simple task like"enter code for this functionality".. with detailed discussion on it, so we can keep track of everything said on it (no copy paste of emails, someone in charge of this would enter a few lines to summarize the important points).. you would do it, and send an email to a mailing listsaying "completed task XXX" with the number of the task... we'll use trac for this kind of job... we will also use SF.net's 'tasks' system... we'llsee all that in time... now, here's the thing.. you implement a feature, so you send an email tosay 'I finished this', EACH commit, should have the 'ticket number' whichmeans you are NOT ALLOWED to commit anything if it's not already enteredin the system as a ticket... so if you want a new feature, you would send a mail to the admin (me) with an explanation of what you want and ask fora new ticket to be created.. once it's accepted and created, I'll send amail telling you "here's your ticket", then you have the right to add yourfeature and commit your change with the ticket number in the comments of the commit...I assume that when an user reports a bug in the bug tracking system that counts like a ticket that dosn't involve having to go through you? Also I assume there will be at least one other admin in case you get too busy.
well, not really, first thing is that when a bug is submitted, the QA team would have to reproduce it, if it's not reproducable, they'll have to get more info from the user.. if they can't, then the bug is dropped, if they can reproduce it, they'll enter a ticket for it with a detailed way to reproduce it (more technical than what a user could give)... so not all bugs submited will get there.. in the same way as not all bugs or FR will be accepted (some features are just not meant to be integrated with amsn)... so QA would be in charge of this... for your second question, yes, I won't be the only admin, as of now, there is also burger and Jerome who will be active.. I'll be more in charge of management of the teams, decisions to be taken, what to do next, which tickets to prioritize, etc... but you won't rely on me to add a ticket to the system, QA team will take care of it, they won't need my approval! being the manager doesn't mean you get no freedom...
Also is the email to the list really required? After all, people can just read the amsn-commits list or the RSS feed from CIA to see what's happening. Thiscould keep the list from getting cluttered. And if we want to discuss a commit, we could just forward the email from the commits mailing list. Ofcouse we still would send new features and changes that affect the users todoc guys.
yes, it is required... for many reasons, first, you may do 10 different commits for one single fix, also, in your commit, you'll write : "changed variable name from this to that, move code there, had problem with API of socket version Xxx, used XGetGeometry to have a workaround", and in the email you'll say "the feature was implemented, you can access it using this menu item or this command line option... you'll get this message sent over d-bus".. these are 2 different scopes for the thing, one is the technical explanation of the fix, the email is for 'QA and docs + archives'.. you must think of it as 'commit messages are for devels to understand and emails are for users to understand'... You will see that having emails sent is a LOT better... we might get 10 commits a day, but one 'SR fixed' email a week..
Each commit that would create a new feature OR have a feature change (newWould having it close automaticly after a certain time be OK? Like setting itcommand line option, new API function, build number changed which makes our internal config file incompatible with a new version (from key/value pairs to XML for config.xml for example)) you would have to CC the doc manager in your 'completed' email.. I will send templates for these kind of files... so something like : ========================================================= Ticket : 1043975 - Request to have a command line option for whatever... Fix date : octeber 10th 2010 Fixed by : Kakaroto Fix information : PARTIALLY FIXED || FIXEDTo complete the feature request, I added a new option -d to be able to dothis...note that if the -d option is supplied, it will override the -c option...What to test : command line options with -d and -c, permutations, and other options, and this ... behavior when having/not having the option enabled in the command line... =========================================================ok, so that's an example.. this email would go to a mailing list with a CC to the QA manager and the doc manager and myself (and the requester of thefeature if any)... a copy should be pasted in the ticket information ontrac, and the ticket set to "needs to be tested"... the doc manager wouldautomatically update his documentation based on this and the QA managerwould automatically test it, make sure it introduced no side effect bugs,and then close the ticket if it's perfect...to "pending" on the sf.net tracker?
nooo... amsn is a project that has been up for 5 years now I think.. some bugs remain from that time, it's not because they are old that they should be forgotten.. at my job, I've just implemented a fix and a feature that were requested one year and a half before... Don't forget one thing, the bugs will be maintained by QA team, so all tickets are valid, they are reproducable.. bugs from trackers that were not reproducable can be set to pending and closed, no prob, but not the 'officially accepted tickets'.. we might after some time decide that the cost of implementing a feature would be too much compared to implementing other, more interesing feats, and we might set the ticket to 'dropped'... but we could also keep it with a low priority and some day, we might fix those.. example, now, amsn1 is getting more and more stable and we're trying to polish it even more.. 2 years ago there were bugs we never had time to fix because we have to implement MSNP2P, File transfers, etc... but now, we're in polishing phase and we're probably going to fix some bugs that were submited 3 or 4 years ago (I know there are some in the trackers...)
I already do that, kmail allows me to set a TODO tag on messages I want tothis will assure us that the docs are always up to date, that everything is documented in the meaning that you are to fix a bug, and you see"humm.. to fix the bug I have to remove this bit of code, but that code isthere specifically to do something, why was it added in the first place ???", you look at CVS history, you get the commit, if you don't have enough info from the commit log, you can see the ticket number, go to trac, search for the ticket, and see detailed info about the bug/feature that was requested, also, about who fixed it, who asked for it, when was it done, etc...This is what I meant by we need people to be serious, because I don't want to send an email to someone in docs and never get a reply after a month ortwo... and never see a change... we need people to be ORGANISED! which mean an email client where incoming mail would go to a certain dir, whenyou finish something, you move the mail to a 'done' dir, you tag emails as'TODO' and have a followup directory, and if after a week you didn't get the chance to document something in your followup dir, answer the posterand say 'hey, I got your mail, don't worry, it's not lost somewhere, I'm abit busy, I'll take care of it when I can, but don't worry, it's in my followup directory'.. so we're not like 'when is the work gonna be done ???'reply to. Then when I am bored I just filter for them and reply.
well, perfect.. I also do that lately, but there are two things, flagging the mail, and having a folder for it.. you choose whatever you feel more confortable with, but I like having folders.. something like :
to distribute (inbox) followup social - fun amsn1 amsn2 -libmsn -XML2GUI -tickets fixed -TODOit's easier than just having a flag, it lets you filter your mails correctly, I do it in my job, but not at home, only using the flag.. as I said, that's your choice as long as everyone is organized.
Anyways, this is my fast explanation of a model at almost 1AM and I'mcompletly exhausted... so please, just stop talking about this.. we're notyet into programming, not yet into documenting.. for the moment we're indesigning the teams, then we'll be designing the structure, then choose alanguage, then design the tasks, then divide and assign the tasks, thenstart coding, then the documentation comes after that, then the testing...This model can be very loose, it can be modified to fit everyone's needs,it will be discussed long enough so everyone can get aworking/efficient/trouble-free system to have a great project... so please don't panic and say "ahhh, I don't want to write emails" or "ahhhh, I wantto add whatever feature I wantttt"... we'll see that in time, for now...honestly, now I don't know what I was talking about, I'm really tired.. soreally, sorry, but I'll leave it as it is... my main point was "stop worrying about irelevant things for now... and concentrate on what really matters"..Wait, so was I supposed to comment on it? Don't bother replying if not.
euhh..... ?well, what I said basically was that I was reallyyyyyyyyyy tired and forgot what I was saying and where I wanted to go... so I decided to stop mumbling.. one IMPORTANT thing I forgot to say was that all this should be a system for later, as for now, we're still in design mode, and then we'll implement things, so we don't have 'bugs', everything is new.. so this system will probably be looser than this but once we 'release' and begin having bugs entering, we'll probably have to follow this system... it's still to be discussed, I just draw the main lines, details are to be defined and documented somewhere...
I don't think so, this should be a simplish project. Once it's done (fully follows the spec) I won't have much to do other than fix bugs. After that I>> * aMSN Team (amsn1 ?).............(everyone) >> * aMSN2 Team (amsn2) >> - libmsn team ....................(Youness, GrdScarabe) >> - D-bus for Tcl team .............(Karol) >> - telepathy to GUI layer team ....(?) >> - XML2GUI team ...................(Youness) >> - GUI team .......................(Tom, Lee) >> - Web/Documentation.......(Lee, Diego, Yves) >> - QA..............................(?) I will need someone to help me for the XML2GUI project, I think Phil on the libmsn team (confirm please) and someone for the layer between telepathy and the GUI... Karol, you think you'll need help ?guess I'll become a "floater", working on random stuff.
ok, as you wish, if you need help, don't hesitate to ask... once we get into design mode (as soon as I finish my exams.. next week...) you'll have to do some research on this and give time estimates (in work days, not 'I'll finish at February 3rd', but more like 'I'll need 15 days to work on it, I don't know when I'll have 15 days free, let's hope it's before the end of February...." ) so we can evaluate everyone's work.. once you become a floater, you can do what youwant, but I'd like to know if you would like to contribute elsewhere ? QA, docs ? GUI? another team ? or just stay a floater for the amsn1 team...
Anyways, thank you for reading my mail and taking the time to answer me, I appreciate it :)
I now have to go to bed, so good night all! KaKaRoTo
Tom, Lee,good luck, I think you're on the right track already... web/doc, perfect,we'll assign managers of each team later... QA who wants to ? ohh.. there were some questions from scarabe too : > The questions are : > - Do these groups correspond to the work we have to do ? yes, of course, what do you mean ? > - Who are the responsibles/leaders of each group ? we'll see, we don't even know who's in the groups... but basically, I'll be the manager of everything, I can be manager of all groups + of all individual group > - How do they refer with each others ?what do you mean ? they will be individual projects.. the only thing thatneeds to understand the other projects is the telepathy2GUI layer, whichwill be easy to do as long as the public interfaces that we define in thedesign phase NEVER change... > - What are the artifacts that will preserve us from interfacing > problems ? what do you mean ? > - How will every team refer to the global leader (Youness ?)also what do you mean ? refer to ? there are emails... hehe, I didn't getyour question > - How will documentations/specifications live together ? I think I just explained it> - Do we create a new list to preserver each branch from the development> of the other (this list is quite missy now ) ?yes of course, a new list... a new list for all discussions, maybe a listfor each individual project + one for all projects + one for specific tasks (like for documentation-TODO and for 'ticket-completed',etc...) everyone should be subscribed so this way we all get the same messages,but we would have the messages filtered in an easy way (and we may have abot listening to some lists, like the doc and which would organise things... like a 'add-to-wiki' mailing list which would have a botsubscribed and which would add to the wiki directly and answer you with alink, you would only have to link to the page from wherever you want)> - How insuring code quality/clarity in the new branch ? (cvs masters ?)I never understand your questions!!! and lastly, about chat logs, no, it's not automatic, it's not stored anywhere either.. it's actually the log of the bot, which can be transformed into an html log file using a script (reads the bot-log file and create a chat-log file).. I would need a cron job to do it, and basically a script that would make sure the file is in .gz format (which means the log file is completed) and wasn't already extracted (logs are stored per day 20051210.gz 20051211.gz, etc... and you do a ./createchatlog 20051210 for example)... once I have that and create a cron job, we'll be able to have per-day chat logs... KaKaRoToOn Mon, 12 Dec 2005 23:21:32 -0500, Lee Olson <[EMAIL PROTECTED]> wrote:> On 12/12/05, GrdScarabe <[EMAIL PROTECTED]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>Personnally I'd like to work on libmsn with Youness if everybody >> >> agree ... >> >> * aMSN Team (amsn1 ?).............(everyone) >> * aMSN2 Team (amsn2) >> - libmsn team ....................(Youness, GrdScarabe) >> - D-bus for Tcl team .............(Karol) >> - telepathy to GUI layer team ....(?) >> - XML2GUI team ...................(Youness) >> - GUI team .......................(Tom, Lee) >> - Web/Documentation.......(Lee, Diego, Yves) >>>> >>Do we continue working on the list ... I'm not against the IRC but :>> >> - there is no historic of what is said >> > >> > I think Youness is logging it all with his bot. >> >> That's cool ! Are the logs published somewhere ? >> >> I'm ok to work on documentation too if needed ... >> >> What do you think, instead of a team "documentation" to have a >> responsible for documentation/relations in each team ? >>>> It will be easier for someone involved in the coding to document a part>> that someone totally out of the development ! >> >> I'm also thinking to litterate coding ... but I don't know how all of >> you consider this method ... > > I would appreciate your help in documentation. Once I have more time > to get things organized, I would like to start assigning documentation > tasks, but until then, we need to clean up what we currently have on > the wiki and other places. > > Developers will need to consult with a documentation manager so that > we can merge documentation from the developer when they are adding > something new to aMSN, or documenting something technical that a > documentation member would not necessarily be able to explain quite as > well. I like the idea of having documentation relations with each > team, but we must also think of how the documentation will all come > together as a whole. > > I suppose each documentation relation from each team would combine the > documentation which they receive and give it to the head documentation > manager, who would organize everything and make sure it's presented in > a clear, readable, and standard way. > > We must also consider how the wiki is maintained. Maybe we need to > establish a maintainer for that just to make sure that things are > being kept organized and up to date. > > ~Lee > >> GrdScarabe >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.2 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >> iD8DBQFDnkTbPmfsnt4Id3wRAtDCAJ9K+UlmXmybnQfsurbSJmr4sy1p3QCfWJv+ >> /oGwEn5x6nu7n/o8nbehdcY= >> =lK8P >> -----END PGP SIGNATURE----- >> >> >> ------------------------------------------------------->> This SF.net email is sponsored by: Splunk Inc. Do you grep through log>> files >> for problems? Stop! Download the new AJAX search engine that makes>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel
-- KaKaRoTo ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
