delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/08/15/14:45:45

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
Message-id: <502BEE3D.8050105@unige.ch>
Date: Wed, 15 Aug 2012 20:45:17 +0200
From: Juergen Harms <Juergen DOT Harms AT unige DOT ch>
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>
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).

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019