Hi Aldo, Happy to read you again.
Last week, i have proposed to use SourceForge CVS for start a bug fix branch on 665 release. I have play a little with CVS, and i think i can setup CVS like this. 1) Tag current CVS source code as Win32-GUI-0_0_622. I have notice a problem with text files. Each line end with CRCRLF. I found this in TortoiseCVS FAQ : http://www.tortoisecvs.org/faq.html#sharelinux I have fix this in my home repository, so i can correct it before. 2) Upload 665 code and tag it as Win32-GUI-0_0_665 3) Make a Win32-GUI-0_0_665-Fix branch and use this branch for fix bug. So, we can continue to use main branch for new version. If you are agree, i can do the job and start to work on 665 fix branch. I probably take a look on next release too ;) Kwiki it's a good idea. It's very easy to install/customize/use. Why not use SourceForge Web Space (i read somewhere it's possible to use perl cgi). Laurent. > > Glad to hear from you again. I would like CVS commit access on > SourceForge, user name guruglenn although I may not be able to use it > until next year (but that's only a couple months away). Thank you. > > I'm glad to hear you are working on NEM, as I think it is a friendlier > model overall. Unfortunately, due to timing, I must proceed with my > current project using the old event model + bug fixes. > > Regarding bugfixes, it would be nice to have them available on the > current code base, but at this point, with many non-working features in > your current development code base, it seems like simply releasing it > wouldn't be practical. > > Although I haven't yet figured out SourceForge's CVS implementation, I > know the general capabilities of a source code control system, having > worked with SCCS, RCS, and ClearCase. And I think CVS is built on top > of SCCS or RCS, so has the same capabilities, just packages them nicer? > At least, I think that is how it started... Anyway, perhaps it would > be nice to have two branches... a development branch and a bugfix branch. > > Perhaps you could continue on the NEM on the development branch, and let > other people work on the bugfix branch, fixing bugs, and perhaps doing > minor enhancements. > > If this sounds good to you, perhaps someone (I'd volunteer starting in > Jan, but if there are other volunteers that's OK) could be the > designated "pumpking" for the bugfix branch. > > On approximately 11/17/2003 2:47 AM, came the following characters from > the keyboard of Aldo Calpini: > > hello Win32::GUI people > > > > I'm here, I'm here! I'm very, very sorry for my latitance. I know I > > have promised a lot of things, a lot of times, and never respected > > what I said. please accept my excuse for this. > > > > and I'm very, very happy to see things moving and people willing to > > help. as it is clear at this point, I'm not in the position to continue > > developing Win32::GUI all alone. but I'm not going to give up the project. > > if there is something useful for the community I can do acting as a > > coordinator (sort of "pumpking", in Perl terms), I'll be very happy to > > coordinate. if someone feels like taking over the whole stuff, I'll be > > very happy to be just a member of a team of developers. > > > > my current development version of Win32::GUI has many bugfixes, but the > > internals are being heavily reworked (to support NEM more "natively") > > and there are many non-working features. as an open question to anyone > > interested, I ask: do you think it is better to keep the "rewrite" off > > for a while and work on bugfixing the current release, or do you > > prefer working with me on the new internals? > > > > I can give all the tech help (eg. about XS and about how Win32::GUI works) > > to people who want to be part of the dev team. there's a mailing list > > (perl-win32-gui-hackers) that I set up just for this task. > > > > so, if you want CVS commit access on SourceForge, just give me your > > SourceForge user name and I will set it up. the -hackers mailing list > > can also be used to ask questions about how SourceForge and/or CVS > > works. > > > > regarding the documentation, I appreciate what Erick did, but I found > > it a little difficult to work with. I think a wiki (with CGI::Kwiki, > > for example) would be a better start. we could also write in POD so > > that the documentation could be more easily integrated in the CPAN > > distribution. > > > > I'm still backlogging all the messages on the list, so I will have > > more to elaborate on later. for now, please accept my most sincere and > > humble apologies for being such a non-existant person for so much > > time :-( > > > > > > cheers, > > Aldo > > > > __END__ > > $_=q,just perl,,s, , another ,,s,$, hacker,,print;
