X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-MailCleaner-SPF: none MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Message-id: <502BEE3D.8050105@unige.ch> Date: Wed, 15 Aug 2012 20:45:17 +0200 From: Juergen Harms User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120717 Thunderbird/10.0.6 To: geda-user AT delorie DOT com Subject: Re: [geda-user] Version planning References: <502A7291 DOT 90206 AT unige DOT ch> <20120815155142 DOT 30385 DOT qmail AT stuge DOT se> In-reply-to: <20120815155142.30385.qmail@stuge.se> Content-transfer-encoding: 7bit Reply-To: geda-user AT delorie DOT com On 08/15/2012 05:51 PM, Peter Stuge wrote: > Is there any problem with tagging the git tree somewhere in that period? That is evidently possible. I see the following issues - For somebody from outside the geda development community it is quite difficult to decide on an appropriate moment to take a snapshot of the git tree, with the risk to select and publish a momentarily unstable situation. - There is also a formal consideration: Geda software published in an "official" Mageia release should refer to something officially tagged by Geda, rather than - and wording it with some exaggeration - software selected in an arbitrary choice by somebody from outside Geda. In case that choice is unfortunate, the quality of Geda might be blamed rather than the method used for the import into Mageia. - The Mageia rpm building procedure needs some repository that contains the tarball (and the rpm "spec-file" records where that is); that is normally the upstream site / sourceforge repository. But this is not a serious argument, an appropriate place should be easy to find. On the base of these considerations, and in the absence of urgent reasons to go beyond the present official state of Geda tarballs, I decided not take this approach. As a compromise it might be possible to select some few, but important modifications from the git and to make the Mageia packages (based on the official Geda tarballs) with these modifications applied as patches. That would require careful testing and QA - problematic without good reason. Mageia 3 is planned to be formally released 20.3.2013, and will be succeeded by Mageia 4 somewhere by end 2013. The pair of pcb-201110918 and geda-gaf-1.7.2 is not so bad - and: looks better than what Debian intends to do. (- But I agree with you, the question of principle remains: how to proceed if the next time around git has some very attractive improvements, or if there is strong user demand for an advanced version? Juergen Re Mageia release cycle: there has been a long and quite violent debate on that issue, terminated by a council decision to set this period to 9 months - a compromise value (personally, I was positively surprised by the demonstration that a community distro can rapidly and efficiently take such a decision).