gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] repository options, decision-making and timing


From: David Grant
Subject: Re: [Gnumed-devel] repository options, decision-making and timing
Date: Thu, 04 Mar 2004 02:36:57 -0500
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

My opinion is that the repository issue is a low-priority item, unless others find CVS's inability to rename directories and preserve the revision numbers so crippling that they must change. As far as I'm concerned that been my only complaint. Besides that, it is great, and it is stable and mature, and all developers know it. Changing to something else might throw off new developers. I think subversion uses mostly cvs syntax so migration to that would be easy I think. But still taking all the factors into account, I think gnumed should stick to cvs at this stage. The earliest point would be whenever subversion becomes stable. I would define "stable" as being, whenever debian gets a subversion package into debian-stable.

David


James Busser wrote:

In an earlier posting, Arch had been suggested as an alternative to both Subversion (which itself had some earlier discussion), and the venerable CVS. I do not have enough knowledge or experience to participate in the ultimate decision, but one person's summary at http://www.onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html? page=last&x-showcontent=text seems typical of the views available on the subject therefore I ask:

1. is there any disagreement that GnuMed should move, at some point in the not-too-distant future, to something other than CVS?

2. are the practical choices limited to Subversion or Arch, or is it felt any other options (Aegis) should be considered? How to decide - must-have features vs. certain existing developers being unable to use it vs. any dependency on free Free/Open Source Project Hosting (FOSPHost) Sites

3. what timing of any change would make the most sense? it seems to me that once the v 0.1 alpha is available, there may be increased feedback and suggestions for improvement. Therefore, options:

- get v 0.1 packaged, and limit improvements to those required to get it to download correctly plus / minus filling any holes in documentation. Move to the new repository as the means to incorporate fixes to the 0.1 version

- postpone further, in order to incorporate improvements in all of the "must have 0.1 functions" and THEN freeze further development until moved to the new repository?

- other



_______________________________________________
Gnumed-devel mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnumed-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]