Re: Addressing MC stagnation.
Hi, Leonard! On Mon, 2005-05-23 at 21:41 +0200, Leonard den Ottolander wrote: ?? Aren't you saying what I'm saying? MC_4_6_1_PRE should become mc-4.6.1 and HEAD should be used for the release of 4.7 (the viewer code is not well tested so I believe it shouldn't be used for 4.6.1). Where do we disagree? I misunderstood you as saying we should use MC_4_6_1_PRE branch for 5.0 and further releases. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation - wiki example
Sounds good - let me know if I can be of any assistance at all. -- Regards, Scott --- [ Miguel de Icaza ] ===--- Hello, Thanks for the offers to host the Wiki. At this point, I would like to use the setup that we have at Novell, if only because we get full time system administrators and backup for free. Miguel. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hello mc-devel, Miguel, On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote: Hello, Thanks for raising this issue up, I think that we should proceed in various stages to address some of the problems that we have today in mc: * The website should move to a Wiki. I will have our sysadmins setup a Wiki for MC based on the success we have had with Hula, Mono and Beagle. The use of the Wiki means that users can effectively contribute to the well state of the project, documentation, tutorials and addressing problems that people face. Also using the forum feature and discussion is a good way of keeping archives easily accessible to everyone. * Release-often: MC has not been officially released for a long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. Sounds good to me. What about releasing mc in a given time period to prevent a lingered release cycle? Releasing a new mc (with changing its middle release number for instance) two times per year, say 1st Jan and 1st June, would be good at least for the downstream maintainer's point of view. Furthermore awareness of incoming release motivates people contributing to mc development to send all important patches before the date if they want to see them committed in the next release. Cheers, Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ The worst evil in the world is refusal to think. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation - wiki example
Hi all. I own LRSE Hosting. If you need hosting, I'd be happy to setup a virtual server for MC to host a wiki/slash/scoop whatever site. Free of charge, of course. I'd just be happy to be able to give a little back for such a great program. -- Regards, Scott --- [ Peter Masiar ] ===--- Pavel Roskin wrote: For the Wiki, all we need is a domain name (or we can keep it under the obscure url we can put it on). I have midnightcommander.org registered on Gandi. I can set its IP address to anything. But I don't have any servers to host Wiki. I host CGI::Application 'Best Practices' wiki, http://twiki.med.yale.edu/twiki2/bin/view/CGIapp/WebHome just for kicks set up MC wiki here: http://twiki.med.yale.edu/twiki2/bin/view/MC/WebHome I do not claim this should be 'The MC wiki' - just to show how easy will be to others to contribute with info, links, docs, etc, if we use wiki. How even non-coders (like me) can contribute to most important tool (at least for me). I do not have a logo yet (image is broken) but I will look something up. I am open for suggestions. :-) -- Peter Masiar, [EMAIL PROTECTED], NEW PHONE: (203) 737-2989 Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu I am not a lawyer. My ideas are NOT binding for University. In doubt, Yale policy right: http://www.yale.edu/policy/itaup.html ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi Pavel, On Mon, 2005-05-23 at 03:20, Pavel Roskin wrote: I would suggest if such a step would be made we use the MC_4_6_1_PRE for this. HEAD is somewhat experimental. I disagree. We would confuse everybody. The 4.6.1 branch should be released as 4.6.1 if at all (maybe as 4.6.2 if there we unofficial 4.6.1 releases). It's the experimental code that should become 5.0 or 4.7 or whatever we choose. If it's too unstable, we could make some prereleases. ?? Aren't you saying what I'm saying? MC_4_6_1_PRE should become mc-4.6.1 and HEAD should be used for the release of 4.7 (the viewer code is not well tested so I believe it shouldn't be used for 4.6.1). Where do we disagree? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi Jindrich, Miguel, On Mon, 2005-05-23 at 12:28, Jindrich Novy wrote: On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote: * Release-often: MC has not been officially released for a long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. I don't see the point of doing a major version jump. Although a lot has been fixed there hasn't been that much new code introduced to justify this. 4.6.1 is fine with me. 5.0 would be more of a release number for when we have full extended charset support and all libraries we depend upon are up to date. Sounds good to me. What about releasing mc in a given time period to prevent a lingered release cycle? Releasing a new mc (with changing its middle release number for instance) two times per year, say 1st Jan and 1st June, would be good at least for the downstream maintainer's point of view. I disagree with this as well ;) . I think the best way to go would be to work out a road map and work towards the milestones. Although I can understand why some projects use a periodic release schedule (like Fedora where it is impossible to synchronize the release of all included packages anyway) it feels very unnatural for a project like mc. We should just try to set up the TODO in such a way that we can have a release once or twice a year (or even more often, but based on a roadmap, *not* a timetable). Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi Miguel, On Sun, 2005-05-22 at 23:46, Miguel de Icaza wrote: long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. I would suggest if such a step would be made we use the MC_4_6_1_PRE for this. HEAD is somewhat experimental. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hello, Leonard! On Mon, 2005-05-23 at 00:09 +0200, Leonard den Ottolander wrote: Hi Miguel, On Sun, 2005-05-22 at 23:46, Miguel de Icaza wrote: long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. I would suggest if such a step would be made we use the MC_4_6_1_PRE for this. HEAD is somewhat experimental. I disagree. We would confuse everybody. The 4.6.1 branch should be released as 4.6.1 if at all (maybe as 4.6.2 if there we unofficial 4.6.1 releases). It's the experimental code that should become 5.0 or 4.7 or whatever we choose. If it's too unstable, we could make some prereleases. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
