Jeroen Demeyer <jdeme...@cage.ugent.be> writes:
> On 2012-03-06 12:12, Keshav Kini wrote:
>> I don't understand why you need to do this. The merge process should be
>> a one-time thing, right? Isn't that what the merger script is for?
>> Doesn't "preparing a release" basically mean finalizing the list of
>> patches that will go into the release, not actually making any commits
>> or putting together any tarballs?
>
> No, "preparing a release" == "while (!finished) {decide on a list of
> patches that will go into the release, actually make the commits and put
> together the tarballs, test the tarballs on the buildbot}".Hmm. OK, I guess it's not that big of a deal. If we are moving away from patches and to a (likely git-based) push-pull system soon, then the entire release management workflow will be changed anyway, so we can discuss it at that time. For now I rescind my request. However, if you could maybe address the two problematic things I mentioned, that would be great too - i.e. save the timestamp when you make .hgtags commits and use the same timestamp when you build later development releases, and perform a separate version.py commit for each development release tag point in a development release, not just the last one. Maybe I can even help you with that (poor as my shell scripting skills are). Do you have your merger script under version control somewhere? Or is it just in /home/jdemeyer/merger12618 on sage.math.washington.edu ? What is "12618" anyway? -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
