On Sep 28, 2014, at 1:13 PM, Sébastien Villemot <sebast...@debian.org> wrote:

> Le dimanche 28 septembre 2014 à 12:53 -0700, John Ralls a écrit :
>> On Sep 28, 2014, at 12:30 PM, Sébastien Villemot <sebast...@debian.org> 
>> wrote:
>> 
>>> Le dimanche 28 septembre 2014 à 12:21 -0700, John Ralls a écrit :
>>>> On Sep 28, 2014, at 10:29 AM, Sébastien Villemot <sebast...@debian.org> 
>>>> wrote:
>>>> 
>>>>> Le dimanche 28 septembre 2014 à 10:04 -0700, John Ralls a écrit :
>>>>>> On Sep 28, 2014, at 9:49 AM, Sébastien Villemot <sebast...@debian.org> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Le dimanche 28 septembre 2014 à 11:34 -0500, Tommy Trussell a écrit :
>>>>>>>> I just noticed GnuCash 2.6.4 has been uploaded to Debian Unstable, but
>>>>>>>> haven't seen a notice here or on the GnuCash.org web site for the 
>>>>>>>> release
>>>>>>>> of 2.6.4.
>>>>>>> 
>>>>>>> I indeed uploaded to Debian the 2.6.4 tarball that is available at:
>>>>>>> 
>>>>>>> http://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%
>>>>>>> 29/2.6.4/
>>>>>>> 
>>>>>>> If I was so quick to notice it, it's because the release had been
>>>>>>> announced long in advance
>>>>>>> (http://wiki.gnucash.org/wiki/Release_Schedule) and also because the
>>>>>>> Debian "Jessie" freeze is getting close and I did not want to miss the
>>>>>>> deadline.
>>>>>>> 
>>>>>>> I guess the release announcement is currently being prepared.
>>>>>> 
>>>>>> The release has not yet officially happened, it’s waiting on the Windows 
>>>>>> and Mac builds. Tagging the release and staging the tarballs has to 
>>>>>> happen the night before the release to set up for those builds. If 
>>>>>> you’ve already released the tarballs to Debian please pull them until 
>>>>>> after the announcement hits the lists. It’s quite possible that a 
>>>>>> problem with either of those builds will cause me to make changes to the 
>>>>>> tarballs which would make your Debian package mismatch the official 
>>>>>> release.
>>>>> 
>>>>> It is too late for this release, but I'll wait for the official
>>>>> announcement for the next releases.
>>>>> 
>>>>> However I think that you should not publish on SourceForge source
>>>>> tarballs that are not considered as final releases. This is very
>>>>> confusing, and can lead to all sorts of misunderstandings and problems
>>>>> (as happened to me). Either use a different numbering scheme (like
>>>>> release candidates with a -rcN suffix), or keep them private.
>>>> 
>>>> It’s only confusing because you jumped the gun and grabbed the tarballs 
>>>> before I announced the release. But I just experimented with the “staging” 
>>>> feature which lets me hide directories (you shouldn’t be able to see 2.6.4 
>>>> in the list, though you can still get at it if you type it into the URL 
>>>> bar). I’ll use that from now on.
>>> 
>>> Well, it's confusing because the unreleased tarball is at the exact same
>>> place and with the exact same filename than the final tarball! And I
>>> have a script that automatically checks for new tarballs at that place
>>> (as do most packages in Debian and other distributions).
>>> 
>>> Anyway, thanks for considering to use a private directory from now on.
>>> That should fix the issue.
>>> 
>>> For the 2.6.4 case, please let me know if you modify the source tarball.
>>> In that case, I will reupload the new tarball in Debian (with a slight
>>> modification of the Debian version number, something like 2.6.4+final).
>> 
>> I don’t know what other Debian builders are doing, but I’ll note that 
>> GC2.6.4 hasn’t showed up on Fedora or OpenSuse. Besides, you said earlier
>> 
>>> If I was so quick to notice it, it's because the release had been
>>> announced long in advance
>>> (http://wiki.gnucash.org/wiki/Release_Schedule) and also because the
>>> Debian "Jessie" freeze is getting close and I did not want to miss the
>>> deadline.
>> 
>> So which is it, automatic script or you being too eager?
> 
> It's a mixture of both: the script notified me about the new release;
> then I took the decision to upload despite the lack of official
> announcement (releases are never uploaded automatically to Debian, for
> obvious reasons; there is always the need of human intervention).
> 
>> If it’s really an automatic script, I doubt setting staged on the SF 
>> directory will fix the issue because your script won’t see that. Ours don’t, 
>> and download the tarballs just fine.
> 
> I verified that the modification that you made works for me. The scripts
> looks at the top-level sourceforge HTML page and scans for new
> subdirectories; since you have hidden the 2.6.4 directory, it is no
> longer seen.
> 
>> Having the same name and same place is necessary because our scripts for 
>> building need to point to that same place, otherwise they have to be updated 
>> twice: Once to build the package and again so that others can use them after 
>> the release. 
> 
> I understand that it is easier that way. I guess you could nevertheless
> have an option to select whether to build from the public location, or
> from a private staging area. Anyway, the solution that you have already
> implemented works for me (as long as you don't forget to do the same in
> subsequent releases…).

I’ve added a couple of notes about setting “staged” to the Release_Process 
wiki, which I use every time so that I don’t forget something.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to