Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#15527 closed enhancement (fixed)

Automatically pick up version for bdist

Reported by: vbraun Owned by:
Priority: major Milestone: sage-6.0
Component: scripts Keywords:
Cc: Merged in:
Authors: Volker Braun Reviewers: R. Andrew Ohana
Report Upstream: N/A Work issues:
Branch: u/vbraun/bdist_version (Commits, GitHub, GitLab) Commit: 7673476bbfdf8522b86eaed8551a2206cdbfac28
Dependencies: Stopgaps:

Status badges

Description


Change History (11)

comment:1 Changed 7 years ago by vbraun

  • Branch set to u/vbraun/bdist_version

comment:2 Changed 7 years ago by vbraun

  • Authors set to Volker Braun
  • Commit set to 7673476bbfdf8522b86eaed8551a2206cdbfac28
  • Component changed from PLEASE CHANGE to scripts
  • Milestone changed from sage-6.1 to sage-6.0
  • Status changed from new to needs_review
  • Type changed from PLEASE CHANGE to enhancement

New commits:

7673476Remove the version argument from sage -bdist

comment:3 Changed 7 years ago by ohanar

  • Reviewers set to R. Andrew Ohana
  • Status changed from needs_review to positive_review

comment:4 Changed 7 years ago by vbraun

  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:5 Changed 7 years ago by kcrisman

Slipped in under the radar! This is nowhere documented (I do not count the usage function because that only shows up if one puts in too many arguments, not "too few"), there is no Trac number in the commit (I still do not understand why this is not considered a serious regression for ordinary people trying to find out when things happened), and I'll point out that http://ask.sagemath.org/question/7979/exact-syntax-for-bdist/ also now is obsolete. The only place where bdist is even mentioned in the documentation is http://sagemath.org/doc/installation/source.html?highlight=bdist and that still has the old syntax. But this is a backwards-incompatible change which just wasted a lot of my time.

comment:6 Changed 7 years ago by vbraun

When you make the commit you can't know for sure in which ticket the commit ends up. You can guess, but if you guess wrong its impossible to change (commits are immutable after all). The ticket can easily be found by following forward to the next release manager commit, e.g. automatized by "git trac find <sha1>"

comment:7 follow-up: Changed 7 years ago by kcrisman

I don't follow. Even if a branch has several tickets it ends up closing, each individual commit should surely be connected (if only morally) to a given ticket? If a ticket is closed as not valid because a later one subsumes it, that is fine - the later one is the ticket. If this isn't possible in the new workflow, at the very least one could go back to the (quite successful, at the time) policy of asking everyone to put the ticket # in the commit message. This seems very reasonable and we already did it.

And now git trac becomes almost necessary, which is sort of unfortunate.

$ git log | grep 15527
    Trac #15527: Automatically pick up version for bdist
    URL: http://trac.sagemath.org/15527
commit 0c2032f1bbf24a1552715ea3bbefd646def0a902
$ git log 0c2032f
commit 0c2032f1bbf24a1552715ea3bbefd646def0a902
Merge: fd93366 8a0a800
Author: William Stein <wstein@gmail.com>
Date:   Mon Aug 27 13:24:26 2007 -0700

    merge

This is even more confusing. In fact, it's commit 15d89e9.

I get that there is this nonlinear structure. But that means the ticket #s are more important, not less, because git log is pretty useless for trying to figure order out (bisecting) and it would be nice not to have to be a git expert to find out what caused a problem.

Anyway, you also shouldn't have to be a git expert - or to have to guess about git trac find since the developer guide section on git trac doesn't have it - in order to guess the ticket.

Nor to guess the version of Sage a given 'ticket' is merged in! Since Jeroen automated these things, I can't see why it is so horrible to try them again... but I suppose I don't have much chance of prevailing here.

comment:8 in reply to: ↑ 7 Changed 7 years ago by vbraun

Replying to kcrisman:

I don't follow. Even if a branch has several tickets it ends up closing, each individual commit should surely be connected (if only morally) to a given ticket?

Yes, but you can only tell for sure after everything is merged. E.g. you make a commit, then discover that ticket is duplicate of another one. Or you might start writing code without a ticket open at all, and only later decide to contribute it.

comment:9 Changed 7 years ago by vbraun

PS: In your grep, the commit sha1 happens to have the search string inside. Its not the commit that you are looking for. You want

$ git trac log 15527
commit 15d89e9d06fd150be0fc741884a8039e9fcac6aa
Merge: 40ed717 7673476
Author: Release Manager <release@sagemath.org>
Date:   Mon Dec 16 22:54:25 2013 +0000

    Trac #15527: Automatically pick up version for bdist
    
    URL: http://trac.sagemath.org/15527
    Reported by: vbraun
    Ticket author(s): Volker Braun
    Reviewer(s): R. Andrew Ohana

commit 7673476bbfdf8522b86eaed8551a2206cdbfac28
Author: Volker Braun <vbraun.name@gmail.com>
Date:   Mon Dec 16 18:52:50 2013 +0000

    Remove the version argument from sage -bdist

comment:10 Changed 7 years ago by kcrisman

PS: In your grep, the commit sha1 happens to have the search string inside. Its not the commit that you are looking for. You want

These aren't the droids you're looking for...

$ git trac log 15527

But don't I need to know the ticket number in the first place to find this?

comment:11 Changed 7 years ago by kcrisman

By the way, I think this shows that the optional directory argument no longer works properly, or so it seems from the way it tries to cd into the temp directory twice... :-(

Note: See TracTickets for help on using tickets.