Le dimanche 18 mars, William Stein a écrit:
> Does git magically solve that problem?
No, but it mitigates it. It's a tool. It won't prevent you from hitting
on your fingers if you insist on it, but it will make your life easier
in general.
Snark on #sagemath
--
To post to this group, send an em
William Stein writes:
> On Sun, Mar 18, 2012 at 8:31 AM, Keshav Kini wrote:
>> William Stein writes:
>>> On Sun, Mar 18, 2012 at 7:59 AM, Keshav Kini wrote:
William Stein writes:
> On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer
> wrote:
>> On 2012-03-17 14:39, Keshav Kini w
On Sun, Mar 18, 2012 at 8:31 AM, Keshav Kini wrote:
> William Stein writes:
>> On Sun, Mar 18, 2012 at 7:59 AM, Keshav Kini wrote:
>>> William Stein writes:
On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer
wrote:
> On 2012-03-17 14:39, Keshav Kini wrote:
>> If you instead tel
William Stein writes:
> On Sun, Mar 18, 2012 at 7:59 AM, Keshav Kini wrote:
>> William Stein writes:
>>> On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer
>>> wrote:
On 2012-03-17 14:39, Keshav Kini wrote:
> If you instead tell people to base
> their patches on the stable release
>>
On Sun, Mar 18, 2012 at 7:59 AM, Keshav Kini wrote:
> William Stein writes:
>> On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer
>> wrote:
>>> On 2012-03-17 14:39, Keshav Kini wrote:
If you instead tell people to base
their patches on the stable release
>>> I certainly don't want this.
William Stein writes:
> On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer
> wrote:
>> On 2012-03-17 14:39, Keshav Kini wrote:
>>> If you instead tell people to base
>>> their patches on the stable release
>> I certainly don't want this.
>>
>>> Why do patches need to be based on the latest dev rele
On Sunday, 18 March 2012 20:57:54 UTC+8, William wrote:
>
> On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer <> wrote:
> > On 2012-03-17 14:39, Keshav Kini wrote:
> >> If you instead tell people to base
> >> their patches on the stable release
> > I certainly don't want this.
> >
> >> Why do patch
On Sun, Mar 18, 2012 at 5:45 AM, Jeroen Demeyer wrote:
> On 2012-03-17 14:39, Keshav Kini wrote:
>> If you instead tell people to base
>> their patches on the stable release
> I certainly don't want this.
>
>> Why do patches need to be based on the latest dev release?
What do you mean by this que
On 2012-03-17 14:39, Keshav Kini wrote:
> If you instead tell people to base
> their patches on the stable release
I certainly don't want this.
> Why do patches need to be based on the latest dev release?
To reduce the change of merge conflicts or doctest conflicts (one patch
causing a doctest to
Jeroen Demeyer writes:
> On 2012-03-16 14:01, R. Andrew Ohana wrote:
>> For the same reason you started releasing 5.0 prealphas while
>> finishing up 4.8. It makes sense to continue working on closing
>> various fixes + improvements/features, but you shouldn't be doing this
>> to code that is bein
Le samedi 17 mars, Jeroen Demeyer a écrit:
> On 2012-03-16 14:01, R. Andrew Ohana wrote:
> > For the same reason you started releasing 5.0 prealphas while
> > finishing up 4.8. It makes sense to continue working on closing
> > various fixes + improvements/features, but you shouldn't be doing
> > th
On 2012-03-16 14:01, R. Andrew Ohana wrote:
> For the same reason you started releasing 5.0 prealphas while
> finishing up 4.8. It makes sense to continue working on closing
> various fixes + improvements/features, but you shouldn't be doing this
> to code that is being prepped for release.
Except
In gmane.comp.mathematics.sage.devel, you wrote:
> On Fri, Mar 16, 2012 at 7:47 AM, Keshav Kini wrote:
>> "R. Andrew Ohana" writes:
>>> This makes it obvious that I'm against having later versions of sage
>>> be based upon previous versions, however, I am completely for later
>>> versions of sage
William Stein writes:
> On Fri, Mar 16, 2012 at 7:47 AM, Keshav Kini wrote:
>> "R. Andrew Ohana" writes:
>>> This makes it obvious that I'm against having later versions of sage
>>> be based upon previous versions, however, I am completely for later
>>> versions of sage having all of the commits
On Thu, Mar 15, 2012 at 10:56 AM, Keshav Kini wrote:
> Robert Bradshaw writes:
>> On Thu, Mar 15, 2012 at 3:34 AM, Dima Pasechnik wrote:
>>> On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote:
Okay, I'll think about your suggestion and changing the merger
procedure.
On Fri, Mar 16, 2012 at 08:03, Julien Puydt wrote:
> Le vendredi 16 mars, Keshav Kini a écrit:
>
> If a later version contains everything gone in a previous version...
> then how is it not based on it?
In the sense that you state: that a release is just a tag on the
master branch. Or in other wor
Le vendredi 16 mars, Keshav Kini a écrit:
> "R. Andrew Ohana" writes:
> > This makes it obvious that I'm against having later versions of sage
> > be based upon previous versions, however, I am completely for later
> > versions of sage having all of the commits of earlier versions of
> > sage (as
On Fri, Mar 16, 2012 at 7:47 AM, Keshav Kini wrote:
> "R. Andrew Ohana" writes:
>> This makes it obvious that I'm against having later versions of sage
>> be based upon previous versions, however, I am completely for later
>> versions of sage having all of the commits of earlier versions of sage
"R. Andrew Ohana" writes:
> This makes it obvious that I'm against having later versions of sage
> be based upon previous versions, however, I am completely for later
> versions of sage having all of the commits of earlier versions of sage
> (as well as all relative order maintained).
Just to be
On Fri, Mar 16, 2012 at 06:00, Julien Puydt wrote:
>> beta branch: these would be introduced when the release manager has
>> decided to cut off new features from the next release. these would be
>> heavily tested across many platforms until it was determined stable
>> enough for release, at which
> Why make a difference between "beta branch" and "master branch"? I
> don't really see how they could differ in practice.
For the same reason you started releasing 5.0 prealphas while
finishing up 4.8. It makes sense to continue working on closing
various fixes + improvements/features, but you s
Le vendredi 16 mars, R. Andrew Ohana a écrit:
> On Thu, Mar 15, 2012 at 17:59, Julien Puydt
> wrote:
> > Notice that in (1), rel1 might be what is called a "devel release" ;
> > while in (2), that will just be a "stable release" : what is the
> > point of having "devel releases" when your living t
On 2012-03-16 13:50, R. Andrew Ohana wrote:
> master branch: this is where developers should pull from the vast
> majority of the time
>
> beta branch: these would be introduced when the release manager has
> decided to cut off new features from the next release. these would be
> heavily tested ac
On Thu, Mar 15, 2012 at 17:59, Julien Puydt wrote:
> Notice that in (1), rel1 might be what is called a "devel release" ;
> while in (2), that will just be a "stable release" : what is the point
> of having "devel releases" when your living tree is available for all
> to base their work on?
I agr
On 2012-03-16 13:32, Julien Puydt wrote:
> Le vendredi 16 mars, Jeroen Demeyer a écrit:
>> On 2012-03-16 01:59, Julien Puydt wrote:
>>> your living tree
>> which means what?
>
> It's live vs record.
>
> Developers see where you are directly. You review a patch on trac, you
> say: "Ok, it's in!" a
Le vendredi 16 mars, Jeroen Demeyer a écrit:
> On 2012-03-16 01:59, Julien Puydt wrote:
> > your living tree
> which means what?
It's live vs record.
Developers see where you are directly. You review a patch on trac, you
say: "Ok, it's in!" and indeed, it's there. No need to wait for the
next sna
On 16 Mrz., 01:52, Dima Pasechnik wrote:
> Should we invite Linus to do a demo release for us (unless Jeroen objects)?
> /me *hides*
Greg KH has some nice series in his blog about certain kinds of
requests, see
http://www.kroah.com/log/linux/maintainer-06.html
--
To post to this group, sen
On 2012-03-16 01:59, Julien Puydt wrote:
> your living tree
which means what?
--
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
Le jeudi 15 mars, Georg S. Weber a écrit:
>
What I would like to point out is :
(1) current situation : I base my work on rel1,
and when I'm happy with it, learn that there is a rel2 which is
rel1+patch1+...+patch100, with seven conflicts, and I should rebase.
(2) a proper source management sys
Should we invite Linus to do a demo release for us (unless Jeroen objects)?
/me *hides*
--
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://gro
Hi Keshav,
that's the diagram I have the most stomachache with:
(snip)
>
> How it would work given current practices
> -
>
(snip)
>
> 5) Another release is made, incorporating the developer's changes (X, M,
> and Y), but first backing out the changes made i
On 2012-03-15 18:56, Keshav Kini wrote:
> Of these three things, IMO the most important is patches vs. push/pull .
> I really just made this thread in the hopes of getting the destroying
> history problem out of the way so that it won't stand as a barrier to
> switching to push/pull (though it is b
Robert Bradshaw writes:
> On Thu, Mar 15, 2012 at 3:34 AM, Dima Pasechnik wrote:
>> On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote:
>>>
>>> Okay, I'll think about your suggestion and changing the merger
>>> procedure. But I'll be honest that this is not too high on my list of
>>
William Stein writes:
> On Thu, Mar 15, 2012 at 9:22 AM, Keshav Kini wrote:
>> Jason Grout writes:
>>> On 3/15/12 10:10 AM, Jeroen Demeyer wrote:
> Do you have your merger script under any kind of revision control?
No.
>>>
>>> It might make sense to include these scripts with Sage, mana
On 2012-03-15 17:28, William Stein wrote:
> I definitely think the release management scripts should be shipped with Sage.
I wouldn't mind.
I don't feel like this doing this now, though. The current sage-5.0
release is already complicated enough. Maybe something for sage-5.0.1
or sage-5.1.
--
On Thu, Mar 15, 2012 at 9:22 AM, Keshav Kini wrote:
> Jason Grout writes:
>> On 3/15/12 10:10 AM, Jeroen Demeyer wrote:
Do you have your merger script under any kind of revision control?
>>> No.
>>
>> It might make sense to include these scripts with Sage, managed under
>> the sage root repo
Jason Grout writes:
> On 3/15/12 10:10 AM, Jeroen Demeyer wrote:
>>> Do you have your merger script under any kind of revision control?
>> No.
>
> It might make sense to include these scripts with Sage, managed under
> the sage root repository, for example, or in sage/local/bin.
Is the merger scr
Jason Grout writes:
> On 3/15/12 1:53 AM, Keshav Kini wrote:
>> Please tell me if anything else about what I said, in my previous
>> post(s) or this one, is insufficiently clear - I hope the diagrams are
>> of some help! And of course I welcome comments about the other points I
>> have made as wel
On 3/15/12 10:10 AM, Jeroen Demeyer wrote:
Do you have your merger script under any kind of revision control?
No.
It might make sense to include these scripts with Sage, managed under
the sage root repository, for example, or in sage/local/bin.
Thanks,
Jason
--
To post to this group, sen
On 2012-03-15 16:01, Keshav Kini wrote:
> Thanks! Again, I would be more than willing to try to make the changes
> myself, or at least some of them, if I can. Can you confirm that the
> latest version of your merger script (i.e. the one I should play with)
> is in /home/jdemeyer/merger12618/ on box
Dima Pasechnik writes:
> well, I think that Keshav's approach is very important if we want to decrease
> the huge rate of bitrot we have now
> with patches that did not make it into a release quickly.
> As the current scheme of things destroys the history of development, it gets
> hard to recrea
Jeroen Demeyer writes:
> Okay, I'll think about your suggestion and changing the merger
> procedure. But I'll be honest that this is not too high on my list of
> priorities.
Thanks! Again, I would be more than willing to try to make the changes
myself, or at least some of them, if I can. Can you
On Thursday, 15 March 2012 20:37:36 UTC+8, kcrisman wrote:
>
>
>
> On Mar 15, 6:34 am, Dima Pasechnik wrote:
> > On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote:
> >
> > > Okay, I'll think about your suggestion and changing the merger
> > > procedure. But I'll be honest that
On 3/15/12 1:53 AM, Keshav Kini wrote:
Please tell me if anything else about what I said, in my previous
post(s) or this one, is insufficiently clear - I hope the diagrams are
of some help! And of course I welcome comments about the other points I
have made as well.
1. First of all, it seemed
On Mar 15, 6:34 am, Dima Pasechnik wrote:
> On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote:
>
> > Okay, I'll think about your suggestion and changing the merger
> > procedure. But I'll be honest that this is not too high on my list of
> > priorities.
>
> well, I think that Kesh
"Georg S. Weber" writes:
> On 14 Mrz., 20:43, Jeroen Demeyer wrote:
>> On 2012-03-14 19:20, Keshav Kini wrote:> If we switch to git, as I
>> understand we eventually will, patches
>> > (commits) made from an older dev release will be considered to "not
>> > apply" (not be mergeable) a lot more o
On Wed, Mar 14, 2012 at 2:10 PM, Georg S. Weber
wrote:
> On 14 Mrz., 20:43, Jeroen Demeyer wrote:
>> On 2012-03-14 19:20, Keshav Kini wrote:> If we switch to git, as I
>> understand we eventually will, patches
>> > (commits) made from an older dev release will be considered to "not
>> > apply" (
On 14 Mrz., 20:43, Jeroen Demeyer wrote:
> On 2012-03-14 19:20, Keshav Kini wrote:> If we switch to git, as I understand
> we eventually will, patches
> > (commits) made from an older dev release will be considered to "not
> > apply" (not be mergeable) a lot more often than merely the cases when
On 2012-03-14 19:20, Keshav Kini wrote:
> If we switch to git, as I understand we eventually will, patches
> (commits) made from an older dev release will be considered to "not
> apply" (not be mergeable) a lot more often than merely the cases when
> other people have meanwhile touched the same fil
"Georg S. Weber" writes:
> 1.
> It can guarantee that each "official" release depends linearly on the
> previous oficial release. I.e. there is a well defined (and openly
> communicated/visible) series of patches, that will lead from one
> official release to the next/following one, when these pat
On Wed, Mar 14, 2012 at 9:55 AM, Georg S. Weber
wrote:
> Finally, I'd like to add that in my eyes, Jeroen does a tremendously
> good job in "coordinating concurrent or conflicting changes", to the
> extent that more often than not, it is us fellow developers hanging
> behind after him, not the oth
>
> Frankly said, it is currently *too easy* (for the release manager) to
> abandon changes made to previous, already published [devel] releases
> -- as if they never happened. And whether that's beneficial to the
> development and review process is at least questionable.
>
> 2ct,
>
> -leif
Hi L
On Mar 6, 2:35 pm, "Georg S. Weber"
wrote:
> The downside is, that if two (or more) patches collide (which may not
> easily (or shall not) be put in one and the same "series of patches",
> for whatever reason), only one can win --- and all the others have to
> be rebased on the "then next" officia
On Mar 6, 12:31 pm, Jeroen Demeyer wrote:
> 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 l
On Mar 6, 10:52 am, "Georg S. Weber"
wrote:
> honestly, I don't believe that what you describe, are arguments
> against the workflow as such --- but rather arguments against waiting
> for too long before releasing a new official version. Sage 4.7.2 was
> released in last November, Sage 4.8 in Janu
"Georg S. Weber" writes:
> Yes,
> I can see your point, thanks for clarifying it!
>
> My bad, my mind was still set to the "old" mode that any patches
> simply have to be based against some (preferably the latest)
> *official* Sage release. (With the obvious exception of a series of
> patches wit
Jeroen Demeyer 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 w
On 6 Mrz., 11:44, Keshav Kini wrote:
> "Georg S. Weber" writes:
>
> > Hi Keshav,
>
> > honestly, I don't believe that what you describe, are arguments
> > against the workflow as such --- but rather arguments against waiting
> > for too long before releasing a new official version. Sage 4.7.2
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 a
Jeroen Demeyer writes:
> On 2012-03-06 05:49, Keshav Kini wrote:
>> Hi Jeroen,
>>
>> If I understand correctly, your reasoning for basing new development
>> releases on the previous stable release rather than the previous
>> development release is that sometimes a ticket may be merged into a
>> d
Jeroen Demeyer writes:
>> Until SPKGs are possible to uninstall or
>> downgrade effectively, that is impractical.
> Not really. For Sage purposes, downgrading a spkg is exactly the same
> as upgrading a spkg. It's not like we sort package versions or
> anything, we only check for equality.
No -
"Georg S. Weber" writes:
> Hi Keshav,
>
> honestly, I don't believe that what you describe, are arguments
> against the workflow as such --- but rather arguments against waiting
> for too long before releasing a new official version. Sage 4.7.2 was
> released in last November, Sage 4.8 in January
Hi Keshav,
honestly, I don't believe that what you describe, are arguments
against the workflow as such --- but rather arguments against waiting
for too long before releasing a new official version. Sage 4.7.2 was
released in last November, Sage 4.8 in January, and now it is March
and Sage 5.0 mi
Oops, Jeroen has released 5.0.beta7 since I started writing the above
mail. So I can revise the figures...
fs@boone ~/src/sagelib $ git rev-list
upstream/prerelease-5.0.beta7..upstream/prerelease-5.0.beta4 | wc -l
143
fs@boone ~/src/sagelib $ git rev-list
upstream/prerelease-5.0.beta4..upstream/
64 matches
Mail list logo
