> > Ok, thanks I understood the development situation. I still cannot > > understand why your patch must be checked in right now. > > Like Atsushi pointed out: there is no need to check in this code > immediately (and am still not convinced we should).
Hmm... ok. It may not be checked in "right now". The only reason that I requested for it was: 1. mcs would support "/doc", even if in sometime future. 2. My patch currently does nothing but just collect the comments. So, it could have been the starting point. 3. I did not know that Atsushi is already working on this... so, I thought I've give in my code. 4. It would have not immediately helped out mcs in anyway unless "/doc" was fully supported however it would have helped in mcsdoc since I would not have required "many changes in current mcs" in my mcsdoc repository. As I already mentioned, currently, I have to manually track the changes and update the local copy of mcs in my mcsdoc repository because the cs-parser.jay in mcsdoc and in mcs differ by huge amounts. > > As an example, the generics compiler has been developed on a separate > directory for almost a year, and we have to integrate patches every day. > The anonymous method code lived only on my hard drive as a copy of the > repository for six months, and I had to go through the same problems. Ok. But integrating that is a pain (I assume that's manual). Well, if it's the same case at many places, I would also live with it... :-( > I do not like the idea of checking work-in-progress code to the > compiler, because that code tends to be bit rot if the work is not > completed. Ok. Agree... Hooh! Going by the examples of "generics" and "anonymous methods", I'd let mcsdoc evolve separately and once done report back with final code. -- Cheers, Gaurav Vaish http://csdoc.sf.net -------------------- _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
