The Sage dev scripts

[Nathann Cohen]

Helloooooooooo everybody !

There is no pub in a radius of 40km of where I live, so I spend my evenings rewriting Sage's developer manual.

Tonight I have two questions for you:

1) should we keep the "Sage dev" scripts in Sage ? 

2) Should we keep it in the doc ?

http://www.sagemath.org/doc/developer/

Several reasons:

- Most of our developer's manual is about 'how to use git'. We have:

    - First Steps with Git

    - Git and Trac Integration (contains 'git-trac' and the dev scripts)

    - Git tips and tricks (contains 'git the hard way')

  (All of which appears before the 'sage-specific' doc. Perhaps we should reverse that)

- The 'dev scripts' page begins with a 'hint' recommending to NOT use them (feels like a deprecation already)

- A tool that we do not use ourselves will not be debugged either

Given that we have been using Git for a while now, perhaps we can more easily make up our minds on this respect ?

I believe that two ways to contribute (regular git + git trac) is already a lot, and that we should stick to that. It may also be slightly clearer to newcomers who wonder which of the 3 (!!!) different ways to contribute they should pick.

What do you think ?

Good evening,

Nathann

[Dima Pasechnik]

On 2014-12-26, Nathann Cohen <nathan...@gmail.com> wrote:
> --f46d043c7edc287181050b1f0d5c
> Content-Type: text/plain; charset=UTF-8

IMHO dev scripts should be retired.
Does anyone use them?

By the way, I noticed some change in the behaviour of trac git server;
it seems that fetching u/foo/bar automatically results in
creation of a local branch trac/u/foo/bar.

Is this documented anywhere?

Cheers,
Dima


>
> Good evening,
>
> Nathann
>

[Nathann Cohen]

> By the way, I noticed some change in the behaviour of trac git server;
> it seems that fetching u/foo/bar automatically results in
> creation of a local branch trac/u/foo/bar.
>
> Is this documented anywhere?

No idea. Really, these days I am trying to make the developer's manual
something I can point people to when they have a question to ask. Come
help me, and whenever something is not written add it somewhere. One
day we will not have to answer those questions again, we will just
have to link toward the developer's manual :-P

Nathann

[Volker Braun]

On Friday, December 26, 2014 6:23:43 PM UTC+1, Dima Pasechnik wrote:

By the way, I noticed some change in the behaviour of trac git server;
it seems that fetching u/foo/bar automatically results in
creation of a local branch trac/u/foo/bar. 

No it doesn't. Local branches would be in the output of "git branch". The fetched branch is of course know to the local repo under a name, e.g. in the output of "git ls-remote trac". 

[Dima Pasechnik]

On 2014-12-26, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_5531_1685050387.1419616059330
> Content-Type: multipart/alternative;
> boundary="----=_Part_5532_1775001320.1419616059330"
>
> ------=_Part_5532_1775001320.1419616059330
> Content-Type: text/plain; charset=UTF-8

but then what does the following mean:

$ git fetch trac u/dimpase/16929
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 14 (delta 9), reused 7 (delta 2)
Unpacking objects: 100% (14/14), done.
From git://trac.sagemath.org/sage
* branch u/dimpase/16929 -> FETCH_HEAD
* [new branch] u/dimpase/16929 -> trac/u/dimpase/16929

$ git remote -v
origin https://github.com/sagemath/sage.git (fetch)
origin https://github.com/sagemath/sage.git (push)
trac git://trac.sagemath.org/sage.git (fetch)
trac g...@trac.sagemath.org:sage.git (push)


What does this [new branch] mean?

Note that now I can e.g. do

$ git checkout trac/u/dimpase/16929
Note: checking out 'trac/u/dimpase/16929'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in
this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again.
Example:

git checkout -b new_branch_name

HEAD is now at a576d91... Ported Ingo's code to Sage 6.5.beta1


That is to say, 'trac/u/dimpase/16929' really got created.

Dima

[Volker Braun]

I'd say by definition a git branch is what is listed by "git branch". Having said that, it is just a label for a commit. There are other kinds of labels for commits, for example tags. Whenever you fetch (pull) something from a remote a local copy (of the commits on the remote) is made, and they also have labels. But its not really a git branch, as you saw you can't check it out directly and you can't add commits on top without actually creating a new branch off it.

[Nathann Cohen]

Hey guys... I hate to interrupt your debugging but I had a question
about Sage-devel. Can I create a patch to remove that, in the end ?

Nathann

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/JtVWAdvw-3A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Nathann Cohen]

Hey guys... I hate to interrupt your debugging but I had a question

about <The Sage dev scripts>. Can I create a patch to remove that, in
the end ?

Nathann

[François]

If you do remove them don't forget to remove the associated documentation. That is remove sage/dev but also doc/en/reference/dev and apply this little patch too https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage-doc/files/sage-doc-dev.patch

François

[Ralf Stephan]

Very good. I guess the respective still open tickets

are wontfix then...

[Simon King]

Hi Dima,

On 2014-12-26, Dima Pasechnik <dim...@gmail.com> wrote:
> IMHO dev scripts should be retired.
> Does anyone use them?

I found them quite practical, and you may recall from the discussions in
Paris that I'd like them to be extended so that they are also able to
send bug reports to the bug trackers of Singular/Gap/..., so that there is
no need to google "how to report bugs in Singular".

Nonetheless, I stopped using the scripts, simply because everybody seems
to fancy git-trac now.

> By the way, I noticed some change in the behaviour of trac git server;
> it seems that fetching u/foo/bar automatically results in
> creation of a local branch trac/u/foo/bar.

Seriously? I thought this was the behaviour of the dev scipts. The
git-trac scripts would result in a local branch t/foo/bar or so...

Best regards,
Simon

[Nathann Cohen]

> I found them quite practical, and you may recall from the discussions in
> Paris that I'd like them to be extended so that they are also able to
> send bug reports to the bug trackers of Singular/Gap/..., so that there is
> no need to google "how to report bugs in Singular".
>
> Nonetheless, I stopped using the scripts, simply because everybody seems
> to fancy git-trac now.

Oh.

So what do you think we should do with them ? Remove them from Sage
and keep our 3 tools, or give them up and focus on [pure git/git trac]
?

Nathann

[Dima Pasechnik]

Nathann, that's about git in developer docs, so that's not 100% off the thread :-)

One thing that is confusing in the "Git the hard way" is that the
example of git fetch in
http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets
does not show a line like

* [new branch] u/dimpase/16929 -> trac/u/dimpase/16929

And I vaguely recall that these lines were not always there. (or maybe
my memory fails me).
Now they always are there, at least for me.

Should the docs be updated?

On 2014-12-26, Volker Braun <vbrau...@gmail.com> wrote:
> I'd say by definition a git branch is what is listed by "git branch".
> Having said that, it is just a label for a commit. There are other kinds of
> labels for commits, for example tags. Whenever you fetch (pull) something
> from a remote a local copy (of the commits on the remote) is made, and they
> also have labels. But its not really a git branch, as you saw you can't
> check it out directly and you can't add commits on top without actually
> creating a new branch off it.

I don't follow you here. Are you saying that the part

* [new branch] u/dimpase/16929 -> trac/u/dimpase/16929

of the git fetch report is not correct? It does say 'new branch'!

Dima

> On Friday, December 26, 2014 9:07:06 PM UTC+1, Dima Pasechnik wrote:
>>

[Nathann Cohen]

Yo !

> Nathann, that's about git in developer docs, so that's not 100% off the thread :-)

Well, as long as we can close the question related to the removal of
the sage-dev scripts, I personally don't care what this thread
becomes. But I need to know what to do with that ! :-P

> One thing that is confusing in the "Git the hard way" is that the
> example of git fetch in
> http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets
> does not show a line like
> * [new branch] u/dimpase/16929 -> trac/u/dimpase/16929

I do not understand. "Git the hard way" is about only git: it does
what you want, and nothing else. If you want something like that you
should type:

git fetch trac u/dimpase/16929:trac/u/dimpase/16929

I planned on rewriting this section too in order to explain the
problems related to doing a "checkout" on a very old patch, and the
recompilation that follows. But I expect this patch to be a bit
controversial so I did not touch this section yet.

> Should the docs be updated?

All this manual should be updated, now that we got used to git. So
please help me by reviewing the patches I wrote:

http://trac.sagemath.org/ticket/17551

Nathann

[Dima Pasechnik]

On 2014-12-27, Nathann Cohen <nathan...@gmail.com> wrote:
> Yo !
>
>> Nathann, that's about git in developer docs, so that's not 100% off the thread :-)
>
> Well, as long as we can close the question related to the removal of
> the sage-dev scripts, I personally don't care what this thread
> becomes. But I need to know what to do with that ! :-P
>
>> One thing that is confusing in the "Git the hard way" is that the
>> example of git fetch in
>> http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets
>> does not show a line like
>> * [new branch] u/dimpase/16929 -> trac/u/dimpase/16929
>
> I do not understand. "Git the hard way" is about only git: it does

Once again: whenever I do git fetch from trac I get a local branch
created on the spot:

* branch u/foo/bla -> FETCH_HEAD
* [new branch] u/foo/bla -> trac/u/foo/bla

whereas according to "Git the hard way" it would just do

* [new branch] u/foo/bla -> FETCH_HEAD

Could anyone explain what's going on ?


Dima

[Nathann Cohen]

> Once again: whenever I do git fetch from trac I get a local branch
> created on the spot:

Can you give us the command that you type that produces this result ?

Nathann

[Dima Pasechnik]

On 2014-12-27, Nathann Cohen <nathan...@gmail.com> wrote:

I did give it here:
https://groups.google.com/d/msg/sage-devel/JtVWAdvw-3A/603M_PziLfUJ

(if it matters, my git version is 1.9.1)

[Dima Pasechnik]

just in case, the picture is exactly the same with Sage's supplied git 2.1.2.

[Nathann Cohen]

Yo !

> I did give it here:
> https://groups.google.com/d/msg/sage-devel/JtVWAdvw-3A/603M_PziLfUJ
>
> (if it matters, my git version is 1.9.1)

Ohhhhhhhhhhhhhhhhh !!! That's because your git instal contains a
complete copy of the trac's git server. You've got "ALL" branches on
your computer. So when you download a new branch, it remembers the
remote name that this branch has : trac/u/dimpase/16929

In this case, "the branch u/dimpase/16329 that is on the trac remote".
I used the "--single-branch" flag when I "git cloned" Sage for the
first time, so that only "develop" is linked with trac's develop on my
machine. No other branches

Nathann

[Volker Braun]

I'm in favor of removing the dev scripts eventually, but not right now. There is still some useful functionality for importing old patches, and maybe somebody uses them. The documentation should already be clear enough that this is not the currently recommended way to use git. I'm fine with removing the dev script documentation from the developer guide if you want to simplify it.

[Dima Pasechnik]

On 2014-12-27, Nathann Cohen <nathan...@gmail.com> wrote:

I don't know how one can automatically maintain a mirror of git trac,
without running a special script, and I believe I don't do this.

I just created a frech branch on git trac, from another machine:
clpc171$ touch blah
clpc171$ git add blah
clpc171$ git commit -m 'testing server'
[blah 81e1e09] testing server
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 blah
clpc171$ git push --set-upstream trac HEAD:u/dimpase/blahblahrubbish
Counting objects: 11, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 262 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
To ssh://g...@trac.sagemath.org/sage.git
* [new branch] HEAD -> u/dimpase/blahblahrubbish
Branch blah set up to track remote branch u/dimpase/blahblahrubbish from
trac.

And now on my laptop:

$ git fetch trac u/dimpase/blahblahrubbish
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From git://trac.sagemath.org/sage
* branch u/dimpase/blahblahrubbish -> FETCH_HEAD
* [new branch] u/dimpase/blahblahrubbish -> * trac/u/dimpase/blahblahrubbish

Still the same picture!

Dima

[Nathann Cohen]

> I don't know how one can automatically maintain a mirror of git trac,
> without running a special script, and I believe I don't do this.

I believe that it is what happens in your case, because that's the
default. If you want to check, you can "git clone" Sage again and
fetch a branch from there. You will see that it does not happen (if I
make no mistake).

If you want to try, do a "git clone" again but use the following flags:

-b develop --single-branch

No need to recompile the new copy. Just download it, fetch branches,
see if it does what you want.

Nathann

[Dima Pasechnik]

On 2014-12-27, Dima Pasechnik <dim...@gmail.com> wrote:

And this is the potentially relevant part of SAGEROOT/.hg/config :

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "trac"]
url = git://trac.sagemath.org/sage.git
fetch = +refs/heads/*:refs/remotes/trac/*
pushurl = g...@trac.sagemath.org:sage.git
[trac]
username = dimpase
....

(and I don't have anything interesting in ~/.git* either)

[Dima Pasechnik]

On 2014-12-27, Nathann Cohen <nathan...@gmail.com> wrote:

>> I don't know how one can automatically maintain a mirror of git trac,
>> without running a special script, and I believe I don't do this.
>
> I believe that it is what happens in your case, because that's the
> default.

Are you saying that the default is to constantly pull the data from the
remote, in the background? Really?
Could you point to documentation confirming this?

[Nathann Cohen]

> Are you saying that the default is to constantly pull the data from the
> remote, in the background? Really?

Type "git branch". If you see one thousand things you never fetched
from trac, that's a confirmation.

> Could you point to documentation confirming this?

I do not think that it is written anywhere. I am working on the
developer's doc a lot these days, so if you want it to improve you
can:
1) Write a doc patch, add me in Cc
2) Help me by reviewing my doc patches:
http://trac.sagemath.org/ticket/17545
http://trac.sagemath.org/ticket/17549
http://trac.sagemath.org/ticket/17551

Nathann

[Dima Pasechnik]

On 2014-12-27, Nathann Cohen <nathan...@gmail.com> wrote:

>> Are you saying that the default is to constantly pull the data from the
>> remote, in the background? Really?
>
> Type "git branch". If you see one thousand things you never fetched
> from trac, that's a confirmation.
>
>> Could you point to documentation confirming this?
>
> I do not think that it is written anywhere.

No, really, it's Dropbox that does this, but not git...
(unless git is spyware...)

IMHO, to get the remote branches you'd need to explictly issue
'git fetch' without parameters.

Further, 'Git the hard way' should be consistent, but it
does not tell you about '--single-branch'.

> I am working on the
> developer's doc a lot these days, so if you want it to improve you

well, before improving at this point, we need to dig up the truth :-)

Dima

[Nathann Cohen]

> Further, 'Git the hard way' should be consistent, but it
> does not tell you about '--single-branch'.

Dima: If you want it to change, do something.

1) Write doc tickets
2) help me review mine.

> well, before improving at this point, we need to dig up the truth :-)

I gave you two ways out:

1) Type "git branch" in SAGE_ROOT, tell me if you get 10 lines or 10 screens
2) do a 'git clone' again with the options I gave you, and tell me if
the behaviour is different when you fetch stuff.

Nathann

[Jean-Pierre Flori]

You fetched a remote branch, so git made a local copy of the commits which it is made of (what else could it do?).
Then git decided to give the tip commit two names: "FETCH_HEAD" (because that's what you just fetched) and <remote>/<branch> (that's kind of logical).

I kind of agree with Volker that no branch really got created.
You don't see it when you issue "git branch" without further verbosity.
I'm not even sure that if you don't create a real local branch this "locally copied remote branch" would survive garbage collection ("git gc").

Note that

[mmarco]

I reglarly use the dev scripts. So i would really appreciate if they remain. 

But of course, if they are removed i will adapt to plain git or git trac. But my personal preference is to keep them.

[Nathann Cohen]

> I reglarly use the dev scripts. So i would really appreciate if they remain.

Oh. Well, the developer's manual advises you to NOT use them :-P

> But of course, if they are removed i will adapt to plain git or git trac.
> But my personal preference is to keep them.

Could you why you use them instead of 'git trac' ? Is there something
that they do and that git trac can't do ?

It is a bit about reducing the number of ways to contribute, because 3
is honestly too many.

Nathann

[Volker Braun]

On Saturday, December 27, 2014 1:22:29 PM UTC+1, Nathann Cohen wrote:

Type "git branch". If you see one thousand things you never fetched
from trac, that's a confirmation.

The output of "git branch" will always only contain branches that you created locally.

There is a slight difference between setting up a remote as tracking or not, but that only changes what is downloaded during "git fetch" / "git pull". The fetched data is of course stored locallly, but not as a "branch":

 http://www.patrickzahnd.ch/wp-content/uploads/2014/02/git-transport-v1.pdf

[Nathann Cohen]

> The output of "git branch" will always only contain branches that you
> created locally.

Okay. Then Dima: instead of "git branch" try "git branch -a".

It gives only two lines on my version, but my guess is that it will
take several screens for you.

Only because of the --single-branch flag.

Nathann

[Julian Rüth]

* Nathann Cohen <nathan...@gmail.com> [2014-12-26 19:37:55 +0530]:

> 1) should we keep the "Sage dev" scripts in Sage ?

I regularly use the dev scripts so I would prefer to keep them. I could
of course adapt to using git trac instead if they disappeared so this is
really only a preference.

julian

[Nathann Cohen]

> I regularly use the dev scripts so I would prefer to keep them. I could
> of course adapt to using git trac instead if they disappeared so this is
> really only a preference.

Okay. Do you have any objection to the removal of the documentation ?
We already advise people to not use them, and it would be cool if the
new ones did not learn to use Sage with it.

Nathann

[Volker Braun]

       -a, --all

           List both remote-tracking branches and local branches.

I of course agree that you can set git to not look at remote branches, but as long as you don't explicitly ask for the list of remote branches they are not shown in the output of "git branch". And, regardless of how the remote is set up, remote branches are never local git branches that you can add commits to etc.

[mmarco]

Could you why you use them instead of 'git trac' ? Is there something
that they do and that git trac can't do ?

As i said, it is just what i am used to. It is what i did learn to use in the beginning, and up to now i didn't had any reason to stop using them.  I don't really know what git trac can do because i didn't look at it.

I understand that this is just my personal preference, so it is not a strong reason to take a community decission. I just wanted to state that there is still some people that feels more comfortable with the dev scripts than the other possible choices.

If you want 

[mmarco]

Sorry, it seems my message was interrupted.

If you want to remove the documentation about them from the developper guide, it is ok with me.

[Nathann Cohen]

> If you want to remove the documentation about them from the developper
> guide, it is ok with me.

Okay okay, fine. I think that I will do that then, unless somebody objects.

This way those who still use them can continue, and we hope that in
something like 6 months~1 year you will have switched to git trac or
git by yourself ;-)

By the way, if you feel like learning it now, it would be cool if you
could take a look at the developer's manual and report what is unclear
in there about 'git trac' or 'git the hard way'.

Thanks !

Nathann

[Nathann Cohen]

The branch is there, ready for a review:

http://trac.sagemath.org/ticket/17555

Nathann

[martin....@gmx.net]

Hadn't known of git-trac before. Since the tool has some sage settings hard-wired into it, perhaps it should be called git-sage instead, to avoid clashes?

Recently I've been using git the hard way for pretty much everything except pushing, for which I used "./sage -dev push --ticket" in the hope that that will take care of setting any fields on the Trac ticket that need setting. I had been using the dev scripts more at first, but the mapping between tickets and branch names was a real pain, so anything which can simply deduce the ticket number from the branch name sounds like a good thing to have. Seems I'll have to learn a new way now, but the change seems simple enough.

Reading the documentation now for the first time, some things are not perfectly clear. For example, when creating a ticket, where does the ticket description come from? The printed code snippet doesn't show it, and the text doesn't mention it. The text also doesn't say where the content of the remote branch comes from. So should I do this step at a point where I already have some modifications locally, or can I do this at any time? Does it matter what branch I'm on locally? What's the point of creating a remote branch if I don't have any code at this point? The note about how I could also open a ticket using my web browser is already in the next section, which is confusing.

The “Finishing Up” section isn't perfectly clear either. It mentions “the trac server”, but that could be the git server associated with trac or the trac web interface as opened in a browser. I assume the latter. In which case I'd add my name into the “Authors” field accessible under the “Modify Ticket” section, just as the ticket status is. The note about “first line” is confusing to me. The “Merging” section gives special consideration to the “master” branch, but shouldn't the same consideration also apply to the “develop” branch? Perhaps that section should also discuss the dependencies field for Trac tickets, since when one ticket merges code from another, you'd usually want it to depend on that other as well. You might also want to offer some guideline about the converse: if some code depends on some other code, should you merge branches even though doing so will add code to the diff? In #16571 I decided not to do so, but I had been reading the docs (for the dev scripts) searching for some guideline on this.

So if you want to rewrite the documentation some more, you might want to address some of these things.

[Volker Braun]

On Friday, January 9, 2015 at 5:10:03 PM UTC+1, martin....@gmx.net wrote:

Hadn't known of git-trac before. Since the tool has some sage settings hard-wired into it, perhaps it should be called git-sage instead, to avoid clashes?

My goal was to keep git-trac as independent as possible from Sage. There are only few Sage-specific things in there, but (like trac username/password) could be moved to configuration options inside the repo. I was hoping that our git + track setup would end up being useful for other projects as well.

 Reading the documentation now for the first time, some things are not perfectly clear. For example, when creating a ticket, where does the ticket description come from?

Tickets are created without description. You need a web browser for that. New tickets don't have a branch attached.

The printed code snippet doesn't show it, and the text doesn't mention it. The text also doesn't say where the content of the remote branch comes from. So should I do this step at a point where I already have some modifications locally, or can I do this at any time?

If you already have modifications that are not in a separate branch then put them in a local branch. Ideally, get in the habit of starting a new branch before making changes.

If you aleready have commits in a local branch you can just "git trac push NNNN"  (where NNNN = ticket number)

You can create a new local branch with "git trac checkout NNNN"

 

[Vincent Delecroix]

> 1) should we keep the "Sage dev" scripts in Sage ?

> 2) Should we keep it in the doc ?

There is one very useful thing in the dev script: transform old
mercurial patches into git commit. There are still ticket on trac with
patches and I use this tool from time to time.

Vincent

[kcrisman]

Oh!  I didn't know that - I have wasted a lot of time then doing that "by hand"! 

[Robert Bradshaw]

+1 to getting rid of the sage dev scripts in favor of git-trac (first
the docs, then altogether). Hopefully it's becoming stable enough that
we should start shipping it as part of Sage?

On Fri, Jan 9, 2015 at 9:55 AM, Vincent Delecroix

Perhaps we should go through and convert all old tickets for once and
for all. (Not sure how many wouldn't convert cleanly though...)

[Nathann Cohen]

Hello !

> Perhaps we should go through and convert all old tickets for once and
> for all. (Not sure how many wouldn't convert cleanly though...)

Technically, it should be "feasible" to apply those patches to the
release on which they were based (a loooooong time ago !), and to turn
them into branches (with no conflicts to solve!) even though they do
not apply on the latest beta. It would take some scripting though O_o

Nathann

[Martin von Gagern]

On 11.01.2015 09:38, Robert Bradshaw wrote:
> Hopefully it's becoming stable enough that
> we should start shipping it as part of Sage?

At first I thought so, too. But now I'm no longer sure: if you ship it
with Sage, then it will be difficult to use it if you want to work with
a patch from an older branch. Similarly, if there is some improvement to
the tool, it won't be available when you're working on an older branch
without that. So you'll always have to be careful at what point in
history you're currently operating, to know what tool you have. Having
the tool in an independent repository avoids these issues.

Martin

[Nils Bruin]

On Sunday, January 11, 2015 at 12:54:56 AM UTC-8, Martin von Gagern wrote:

On 11.01.2015 09:38, Robert Bradshaw wrote:
> Hopefully it's becoming stable enough that
> we should start shipping it as part of Sage?

At first I thought so, too. But now I'm no longer sure: if you ship it
with Sage, then it will be difficult to use it if you want to work with
a patch from an older branch.

So we should *ship* it with sage but not *use* it yet. In a year or so, git-trac will have been stable enough for long enough that most people can start using the version shipped with sage, because any branch they meet will have about the same git-trac.

[Simon King]

Hi!

Or: We should ship it with Sage, but it should live in a repository that
is independent of the rest of Sage. Hence, if one works on an old branch
of Sage, git-trac would still be available.

Cheers,
Simon

[kcrisman]

>> > Hopefully it's becoming stable enough that
>> > we should start shipping it as part of Sage?
>>
>> At first I thought so, too. But now I'm no longer sure: if you ship it
>> with Sage, then it will be difficult to use it if you want to work with
>> a patch from an older branch.
>
>
> So we should *ship* it with sage but not *use* it yet. In a year or so,
> git-trac will have been stable enough for long enough that most people can
> start using the version shipped with sage, because any branch they meet
> will have about the same git-trac.

Or, we could keep the dev scripts for those who choose to want to have a "sealed" environment where they can do all Sage work from within Sage? 

[Robert Bradshaw]

Yes, I meant that it should be an spkg. You can install it in old
sage's, you can have a different version, but at least you get some
version by default.