Re: [sage-combinat-devel] Sage 4.4.3
William Stein
<Nicolas...@u-psud.fr> wrote:
> Dear release managers!
>
> What's the current time line for Sage 4.4.3?
>
> We have been working hard those last days on flushing the
> Sage-Combinat queue, and have more than 25 patches with positive
> review ready for inclusion. Well, there is still some work ahead, with
> 15 patches under review and about 125 others still under development :-)
>
> We have a developers meeting on June 14-th - 18-th, and it would be of
> great help if those patches could be merged in 4.4.3 by then, or even
> better if 4.4.3 was released. Any luck?
>
> Thanks!
Basically nobody has been working on Sage releases lately. I did some
work on 4.4.3 during
the first day of Sage days last week, and it has lingered, because I
simply don't have the time.
There are 94 tickets with positive review:
http://trac.sagemath.org/sage_trac/report/32
There is also an alpha1 of sage-4.4.3 here, and two tiny doctests failures
http://sage.math.washington.edu/home/wstein/build/release/4.4.3/sage-4.4.3.alpha1.tar
Failures on sage.math:
sage -t -long "devel/sage/sage/graphs/generic_graph.py"
sage -t -long "devel/sage/sage/sets/set.py"
Total time for all tests: 8037.9 seconds
This fails to build on OS X, due to some changes we made to get it to
build on Cygwin.
The alpha above makes almost no changes to the core Sage library.
Of the "25 patches with positive review ready for inclusion" that you
mentioned above,
are they all changes to the core Sage library? Or do the patch spkg's, etc.?
One possibility would be to test/stabilize the current 4.4.3.alpha*
(i.e., fix the fallout from the cygwin
related tickets), include those 25 patches (all to the sage library),
and release 4.4.3 on Saturday.
If you like that, then make a clean sage-4.4.2, apply all 25 patches,
test it, and I can just pull those
changes in, and that will be 4.4.3.
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
leif
> On Wed, Jun 2, 2010 at 1:31 PM, Nicolas M. Thiery
>
> > Dear release managers!
>
> > What's the current time line for Sage 4.4.3?
>
> > We have been working hard those last days on flushing the
> > Sage-Combinat queue, and have more than 25 patches with positive
> > review ready for inclusion. Well, there is still some work ahead, with
> > 15 patches under review and about 125 others still under development :-)
>
> > We have a developers meeting on June 14-th - 18-th, and it would be of
> > great help if those patches could be merged in 4.4.3 by then, or even
> > better if 4.4.3 was released. Any luck?
new, official release.
(Of course it is worth to know that patches x, y, z are "accepted", or
perhaps cannot [yet] be merged, but that's all, at least to me.)
> Basically nobody has been working on Sage releases lately. I did some
> work on 4.4.3 during
> the first day of Sage days last week, and it has lingered, because I
> simply don't have the time.
> There are 94 tickets with positive review:http://trac.sagemath.org/sage_trac/report/32
>
> There is also an alpha1 of sage-4.4.3 here, and two tiny doctests failures
>
> Failures on sage.math:
>
> sage -t -long "devel/sage/sage/graphs/generic_graph.py"
prepared with Sage (and I guess breaks the notebook output as well).
I've qualified this "critical", though I'd rather consider this a
blocker. (See ticket #9086.)
> sage -t -long "devel/sage/sage/sets/set.py"
> Total time for all tests: 8037.9 seconds
>
> This fails to build on OS X, due to some changes we made to get it to
> build on Cygwin.
>
> The alpha above makes almost no changes to the core Sage library.
>
> Of the "25 patches with positive review ready for inclusion" that you
> mentioned above,
> are they all changes to the core Sage library? Or do the patch spkg's, etc.?
>
> One possibility would be to test/stabilize the current 4.4.3.alpha*
> (i.e., fix the fallout from the cygwin
> related tickets), include those 25 patches (all to the sage library),
> and release 4.4.3 on Saturday.
> If you like that, then make a clean sage-4.4.2, apply all 25 patches,
> test it, and I can just pull those
> changes in, and that will be 4.4.3.
>
> -- William
-Leif
William Stein
On Wed, Jun 2, 2010 at 3:58 PM, leif <not.r...@online.de> wrote:
>> There is also an alpha1 of sage-4.4.3 here, and two tiny doctests failures
>>
>> http://sage.math.washington.edu/home/wstein/build/release/4.4.3/sage-...
>>
>> Failures on sage.math:
>>
>> sage -t -long "devel/sage/sage/graphs/generic_graph.py"
>
> *Tiny* doctest failure?! This might break lots of documentation/texts
> prepared with Sage (and I guess breaks the notebook output as well).
> I've qualified this "critical", though I'd rather consider this a
> blocker. (See ticket #9086.)
Nobody proposed releasing Sage without fixing this.
>> sage -t -long "devel/sage/sage/sets/set.py"
>> Total time for all tests: 8037.9 seconds
>>
>> This fails to build on OS X, due to some changes we made to get it to
>> build on Cygwin.
>>
>> The alpha above makes almost no changes to the core Sage library.
>>
>> Of the "25 patches with positive review ready for inclusion" that you
>> mentioned above,
>> are they all changes to the core Sage library? Or do the patch spkg's, etc.?
>>
>> One possibility would be to test/stabilize the current 4.4.3.alpha*
>> (i.e., fix the fallout from the cygwin
>> related tickets), include those 25 patches (all to the sage library),
>> and release 4.4.3 on Saturday.
>
> Burcin said he won't be able to fix #9086 until next week...
Burcin isn't the only person that knows how to work on Pynac.
>> If you like that, then make a clean sage-4.4.2, apply all 25 patches,
>> test it, and I can just pull those
>> changes in, and that will be 4.4.3.
>
> If module_list.py isn't affected by those patches...
It depends on how module_list.py is effected.
-- William
William Stein
Hi,
I didn't get any feedback on this proposal, and now I've decided to
just do a feature freeze on 4.4.3, since I applied all the
critical/blocker fixes listed on trac, fixed the bugs mentioned before
(with sets and pynac), and just want to release something after going
through the build checklist.
It would make great sense to have another Sage release before June 14.
I don't want to be the one to make it. If you really want one that
definitely has the combinat stuff correctly merged in, perhaps you
could be that release manager, taking the 4.4.3 release as a start?
Robert Miller
I would like to strongly advocate merging #9039, which fixes a rather
important (in my opinion) bug in EllipticCurve().sha().bound_kato().
--
Robert L. Miller
http://www.rlmiller.org/
William Stein
<florent...@univ-rouen.fr> wrote:
> Hi William,
>
>> > One possibility would be to test/stabilize the current 4.4.3.alpha*
>> > (i.e., fix the fallout from the cygwin
>> > related tickets), include those 25 patches (all to the sage library),
>> > and release 4.4.3 on Saturday.
>> > If you like that, then make a clean sage-4.4.2, apply all 25 patches,
>> > test it, and I can just pull those
>> > changes in, and that will be 4.4.3.
>>
>> Hi,
>>
>> I didn't get any feedback on this proposal, and now I've decided to
>> just do a feature freeze on 4.4.3, since I applied all the
>> critical/blocker fixes listed on trac, fixed the bugs mentioned before
>> (with sets and pynac), and just want to release something after going
>> through the build checklist.
>
> arrived here at 00:02:10 this morning and it's now 08:31:50)... Unfortunately
> you bumped away #8881 because I forgot to mention that it depends on #9104.
>
>> It would make great sense to have another Sage release before June 14.
>> I don't want to be the one to make it. If you really want one that
>> definitely has the combinat stuff correctly merged in, perhaps you
>> could be that release manager, taking the 4.4.3 release as a start?
>
> suggest that Nicolas or I could be a release manager while we are struggling
> reducing the queue, organizing a sage meeting in two weeks, answering request
> for documentation and help on categories on sage-algebra and sage-combinat and
> at the same time, closing the academic year in our respective department (Exam
> to prepare and grade -- no T.A. for that here -- student which are making
> summer experience in private companies to visit, evaluations to
> prepare, etc)... I also forgot to add giving two talks (one next Tuesday, one
> next Friday) in some research seminar about sage and its use in our research.
>
> Also, since we are at it, I've no idea how big is the work of a sage release
> manager, but I can tell you that keeping the combinat queue in line against
> several sage release, testing the patch on it and rebasing it at each release
> is a work I feel close (though certainly much lighter) to be the one of a
> release manager. Nicolas and I keep doing it without any allowed break.
>
> I'm sorry for the negative tone of this e-mail but when I said we are
> struggling I meant it. By the way, there is a good risk that Nicolas won't be
> able to answer his e-mail before this evening. So don't expect more feedback.
>
I'm sorry, but sage-4.4.3 is now in feature freeze, since
(1) it is already going to be difficult to release as is,
(2) nobody is helping me,
(3) I don't have much time to work on sage releases right now.
Here's how it will go down:
a. I will do whatever it takes to release sage-4.4.3.
b. I post to sage-release asking for somebody to be release manager
for sage-4.4.4.
-- William
Nicolas M. Thiery
On Wed, Jun 02, 2010 at 03:58:59PM -0700, leif wrote:
> > > We have a developers meeting on June 14-th - 18-th, and it would be of
> > > great help if those patches could be merged in 4.4.3 by then, or even
> > > better if 4.4.3 was released. Any luck?
>
> It is not immediately clear to me why a developers meeting needs a
> new, official release.
> (Of course it is worth to know that patches x, y, z are "accepted", or
> perhaps cannot [yet] be merged, but that's all, at least to me.)
Legitimate question!
Looking back at the last two year the difference between accepted and
merged is non trivial. We got quite a few accepted patches that got
issues during the final merge because of conflicts (more often than
not a typo fix in some patch. Well, usually, it's just a trivial
rebase, but not always. The main point is that, once a patch is
merged, you can *finally* completely forget about it, which is a
serious relief when you have 100+ upcoming patches to manage.
Now, whether having an official release makes it easier or not, that's
indeed by far less critical. It just simplifies things for our
beginner developers not to have to play with the dev versions (they
have already a lot of hurdles to go over).
Best,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
William Stein
Sage-4.4.3 won't be the release you want for this meeting. However, I
think there
will be another "quick" release after it (sage-4.4.4), which will
merge in the combinat patches you
want. Thanks again for giving us a heads up...
-- William
Nicolas M. Thiery
> Sage-4.4.3 won't be the release you want for this meeting. However,
> I think there will be another "quick" release after it (sage-4.4.4),
> which will merge in the combinat patches you want. Thanks again for
> giving us a heads up...
Kudos to whoever is going to manage 4.4.4!
For the record, here is an extract of our current series file:
trac_8500_transitive_groups-final.patch # Positive review
trac_8549_cycle_enumerator-nb.patch # Positive review
trac_8742-lazy_format-fh.patch # Positive review (NT)
trac_8742-lazy_format-review-nt.patch # Positive review (FH)
trac_8926_family_repr-fh.patch # Positive review (NT)
trac_8888_partition_rim-fh.patch # Positive review (JB)
trac_8888_reviewer_jb.patch
trac_8030-stabilizer_bug-nb.patch # Positive review (NT)
trac_8954-nilTemperley-as.patch # Positive review (JB)
trac_8913-cayley_graph_twosided_labels-nt.patch # Positive review (Rob Beezer)
trac_8930-enumerated_set_deprecate-fh.patch # Positive review (NT)
trac_8887-typo_monoid_prod-fh.patch # Positive review (NT)
trac_8902-subsets_call_fix-fh.patch # Positive review (NT)
trac_9104_freemod_name-fix-nt.patch # Positive review (FH)
trac_9096_disj_union_sphinx_fix-fh.patch # Positive review (NT)
# Those are slightly outdated version of #8380 which has a positive review
gap3_interface_v4.3.2.patch #+4_3_3 #-4_3_2
gap3_interface_v4.3.3.patch #-4_3_3
gap3_interface_patch2.patch
trac_8881-functorial_constructions-nt.patch # Positive review (FH)
trac_8910-combinatorial_class_parent-fh.patch # Positive review (NT), depends on #8881
trac_8910-subsets_an_element-fh.patch # Positive review (NT), depends on #8881
trac_9056_semirings_category-nb.patch # Positive review (NT), depends on #8881
trac_9105-categories-primer-improvements-nt.patch # Positive review (FH), depends on #9056, #8881
trac_8890-free_module-cleanup-nt.patch # Positive review (JB), depends on #8881
trac_9106-UniqueRep_sphinx_fix-fh.patch # Positive review (NT)
trac_8811_reduced_word_of_translations-nt.patch # Positive review (AS)
leif
wrote:
>
> On Wed, Jun 02, 2010 at 03:58:59PM -0700, leif wrote:
> > > > We have a developers meeting on June 14-th - 18-th, and it would be of
> > > > great help if those patches could be merged in 4.4.3 by then, or even
> > > > better if 4.4.3 was released. Any luck?
>
> > It is not immediately clear to me why a developers meeting needs a
> > new, official release.
> > (Of course it is worth to know that patches x, y, z are "accepted", or
> > perhaps cannot [yet] be merged, but that's all, at least to me.)
>
> Legitimate question!
>
> Looking back at the last two year the difference between accepted and
> merged is non trivial.
in some merge queue, see below.)
> We got quite a few accepted patches that got
> issues during the final merge because of conflicts (more often than
> not a typo fix in some patch. Well, usually, it's just a trivial
> rebase, but not always. The main point is that, once a patch is
> merged, you can *finally* completely forget about it, which is a
> serious relief when you have 100+ upcoming patches to manage.
snapshots, with positively reviewed tickets being incorporated, i.e.
merged into a central repo, within about a week (but not much quicker,
s.t. there's enough time for other people to test a patch or perhaps
veto against it, currently by reverting the status to "need works" - a
"all or nothing" attribute). This should also prevent lots - or at
least reduce the number - of "new" tickets needing rebase (due to
conflicts with "unknown" older ones). If "long-lasting" (*not* ready
to review) tickets (i.e. their patches) have to be rebased, this
shouldn't be such a surprise, can be performed at (a frequency of)
their authors' taste, and I guess their number won't be that large. Of
course tickets needing review have to be reviewed in time, too (unless
the author doesn't care that much).
By now, "positive review" on trac again is a *boolean* function; it
does neither tell whether a patch has been reviewed by more than one
person, nor on how many systems it has been tested, nor in what
depth.
When a snapshot (not necessarily the "current" one/tip) is regarded
stable enough, a beta or release candidate (source and binary
tarballs) can be made - undergoing thorough testing on all platforms.
If some "random"/external event triggers the need for a final/new
version (e.g. with new enhancements), the same procedure can be
applied, again not necessarily choosing the latest snapshot.
Later discovered bugs (and especially regressions) should be fixed and
merged with highest priority, resulting in a true bugfix-only release.
Sorry, too many words... couldn't resist...
> Now, whether having an official release makes it easier or not, that's
> indeed by far less critical. It just simplifies things for our
> beginner developers not to have to play with the dev versions (they
> have already a lot of hurdles to go over).
Obviously advantageous to have a "fresh", up-to-date release without
pending tickets...
For demonstration purposes, you could of course (at least temporarily)
merge the current combinat queue.
> Best,
> Nicolas
Cheers,
-Leif
Robert Bradshaw
Isn't that what the alphas are?
> This should also prevent lots - or at
> least reduce the number - of "new" tickets needing rebase (due to
> conflicts with "unknown" older ones). If "long-lasting" (*not* ready
> to review) tickets (i.e. their patches) have to be rebased, this
> shouldn't be such a surprise, can be performed at (a frequency of)
> their authors' taste, and I guess their number won't be that large. Of
> course tickets needing review have to be reviewed in time, too (unless
> the author doesn't care that much).
>
> By now, "positive review" on trac again is a *boolean* function; it
> does neither tell whether a patch has been reviewed by more than one
> person, nor on how many systems it has been tested, nor in what
> depth.
>
> When a snapshot (not necessarily the "current" one/tip) is regarded
> stable enough, a beta or release candidate (source and binary
> tarballs) can be made - undergoing thorough testing on all platforms.
>
> If some "random"/external event triggers the need for a final/new
> version (e.g. with new enhancements), the same procedure can be
> applied, again not necessarily choosing the latest snapshot.
> Later discovered bugs (and especially regressions) should be fixed and
> merged with highest priority, resulting in a true bugfix-only release.
>
> Sorry, too many words... couldn't resist...
No, it's good. There's a lot that could be improved.
>> Now, whether having an official release makes it easier or not,
>> that's
>> indeed by far less critical. It just simplifies things for our
>> beginner developers not to have to play with the dev versions (they
>> have already a lot of hurdles to go over).
>
> So in fact it's a developer recruiting meeting. ;-)
> Obviously advantageous to have a "fresh", up-to-date release without
> pending tickets...
> For demonstration purposes, you could of course (at least temporarily)
> merge the current combinat queue.
Of course, that's not quite as nice as telling them they can go
download it on their own and use all the neat features.
Nicolas, would you be willing to partner with me for a release this
summer? A big focus could be getting much of the combinat queue in.
(ideally, they're just ready to pull in, right?)
- Robert
leif
funny, I was just thinking of you (wrt Cython; can you give an
estimate when the "# clib" etc. pragmas will be handled by cython
itself? A fresh final would be a good starting point to apply a new
version of your module_list patches, with immediate commit/re-
release...).
On 4 Jun., 20:36, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> > On 3 Jun., 22:18, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> > wrote:
>
> >> Looking back at the last two year the difference between accepted and
> >> merged is non trivial.
>
> > That's unfortunate. (By "accepted", I actually meant being merged, or
> > in some merge queue, see below.)
>
> >> We got quite a few accepted patches that got
> >> issues during the final merge because of conflicts (more often than
> >> not a typo fix in some patch. Well, usually, it's just a trivial
> >> rebase, but not always. The main point is that, once a patch is
> >> merged, you can *finally* completely forget about it, which is a
> >> serious relief when you have 100+ upcoming patches to manage.
>
> > I'd really like to have (more or less regular, state-driven) developer
> > snapshots, with positively reviewed tickets being incorporated, i.e.
> > merged into a central repo, within about a week (but not much quicker,
> > s.t. there's enough time for other people to test a patch or perhaps
> > veto against it, currently by reverting the status to "need works" - a
> > "all or nothing" attribute).
>
> Isn't that what the alphas are?
releases with developer's, "releases" vs. snapshots).
My current impression is that "releases" (alphas included) appear in
bursts rather than continually, more or less triggered by external
events rather than the state of tickets, and my main objective is to
merge/commit positively reviewed tickets within a defined, shorter
time window.
So parts of what currently a release manager (volunteered for each
release) does, could be performed by a team with commit rights to the
repository. The release manager would then (more or less) "simply"
select the snapshop, create source and binary tarballs (first betas or
release candidates), coordinate/initiate thorough testing of these on
all platforms, and prepare release notes etc., then finally release a
"stable" version.
Also, I think most people (like me ;-) ) always download the whole new
tarball (there are no diffs either), instead of explicitly - perhaps
selectively - pulling in a specific snapshot/[developer] version.
(Downloading/installing only the updated spkgs is currently of course
another option, but they aren't mirrored separately.)
One could of course manually merge whole bunches of patches from trac,
but that's tedious; everybody has to search for them and check which
dependencies exist (and keep track of eventual updates).
> > This should also prevent lots - or at
> > least reduce the number - of "new" tickets needing rebase (due to
> > conflicts with "unknown" older ones). If "long-lasting" (*not* ready
> > to review) tickets (i.e. their patches) have to be rebased, this
> > shouldn't be such a surprise, can be performed at (a frequency of)
> > their authors' taste, and I guess their number won't be that large. Of
> > course tickets needing review have to be reviewed in time, too (unless
> > the author doesn't care that much).
>
> > By now, "positive review" on trac again is a *boolean* function; it
> > does neither tell whether a patch has been reviewed by more than one
> > person, nor on how many systems it has been tested, nor in what
> > depth.
>
> > When a snapshot (not necessarily the "current" one/tip) is regarded
> > stable enough, a beta or release candidate (source and binary
> > tarballs) can be made - undergoing thorough testing on all platforms.
>
> > If some "random"/external event triggers the need for a final/new
> > version (e.g. with new enhancements), the same procedure can be
> > applied, again not necessarily choosing the latest snapshot.
> > Later discovered bugs (and especially regressions) should be fixed and
> > merged with highest priority, resulting in a true bugfix-only release.
>
> > Sorry, too many words... couldn't resist...
>
> No, it's good. There's a lot that could be improved.
seems to be a very small minority that feels uncomfortable with the
current procedure). :)
> >> Now, whether having an official release makes it easier or not,
> >> that's
> >> indeed by far less critical. It just simplifies things for our
> >> beginner developers not to have to play with the dev versions (they
> >> have already a lot of hurdles to go over).
>
> > So in fact it's a developer recruiting meeting. ;-)
> > Obviously advantageous to have a "fresh", up-to-date release without
> > pending tickets...
> > For demonstration purposes, you could of course (at least temporarily)
> > merge the current combinat queue.
>
> Of course, that's not quite as nice as telling them they can go
> download it on their own and use all the neat features.
s.t. one couldn't offer his own release (or snapshot), at least for
workshops etc.; would that bother someone? I cannot really judge this,
but my guess is "no".
-Leif
Robert Bradshaw
> Hi Robert,
>
> funny, I was just thinking of you (wrt Cython; can you give an
> estimate when the "# clib" etc. pragmas will be handled by cython
> itself?
This summer, though I probably won't have a time to look at it for a
couple more weeks.
I'm not sure this would help with the "needs rebasing" issue, as
that's a function of how many other positively reviewed tickets got in
before yours, and whether it happens in bursts or continuously doesn't
matter that much. And until a release is made, even if something gets
merged there's no guarantee that it's in as it may cause problems and
get bounced during testing.
> So parts of what currently a release manager (volunteered for each
> release) does, could be performed by a team with commit rights to the
> repository.
One complication, given that we're shipping a distribution rather than
a single program, is there is not "a repository." This is only a
technical deal however.
I could see this being semi-automated as well. I think it's important
to have a second person look at every ticket (somewhat of a meta-
review) rather than blindly merge everything that's been flagged as
positive. However, much of this could be highly automated. In fact, if
the turn around could be fast enough, I don't think a human should
even bother reviewing a ticket until it's already been automatically
applied and tested fine on at least one machine. (And, while we're on
that note, I'd like a referee.sagenb.org with a worksheet generated
for each ticket so when you go to referee something you can know the
code passed tests, read the code, and try out some examples all online.
I think most people would welcome improvement, especially in making
release management and refereeing easier, but the current system works
"well enough" most of the time that we just deal with it.
Some questions I think we should get input on (perhaps in a more
general forum) is
1) What is the role of a release manager?
2) What does a release manager have to do for each release?
3) What in (2) could not be automated?
>>>> Now, whether having an official release makes it easier or not,
>>>> that's
>>>> indeed by far less critical. It just simplifies things for our
>>>> beginner developers not to have to play with the dev versions (they
>>>> have already a lot of hurdles to go over).
>>
>>> So in fact it's a developer recruiting meeting. ;-)
>>> Obviously advantageous to have a "fresh", up-to-date release without
>>> pending tickets...
>>> For demonstration purposes, you could of course (at least
>>> temporarily)
>>> merge the current combinat queue.
>>
>> Of course, that's not quite as nice as telling them they can go
>> download it on their own and use all the neat features.
>
> Well, I think the risk of forking (without rejoining) isn't that high
> s.t. one couldn't offer his own release (or snapshot), at least for
> workshops etc.; would that bother someone? I cannot really judge this,
> but my guess is "no".
Well, the combinat queue is already kind of like a fork (though always
with the mind of pushing and pulling from upstream. If they were to go
through the testing to do a full release for their positively reviewed
patches, we might as well make it a non-combinat release).
- Robert
William Stein
>> seems to be a very small minority that feels uncomfortable with the
>> current procedure). :)
> Some questions I think we should get input on (perhaps in a more general
> forum) is
>
> 1) What is the role of a release manager?
> 2) What does a release manager have to do for each release?
> 3) What in (2) could not be automated?
[...]
Nobody is jumping up and down volunteering to be release manager.
In fact, I've repeatedly called for volunteers for a release manager,
but there is nobody volunteering. I am concerned that adding a
bunch of rules will make the release manager's job inflexible, more
stressful, and less fun, and less likely to be something a volunteer
would do.
The process by which releases are made should be determined by the
release manager. They should be given a lot of flexibility to try
whatever they want. A useful discussion might be about tools we can
provide the release manager to make their job funner and easier.
Right now, somebody could be merging patches and putting together
sage-4.4.4. There's a brand spanking new clean sage-4.4.3 to start
with:
http://sage.math.washington.edu/home/wstein/build/release/4.4.3/sage-4.4.3.tar
There are a *record* 99 tickets with positive review right here
waiting to be merged:
http://trac.sagemath.org/sage_trac/report/32
But nobody is working on this. That is the real question we
should be worrying about.
Mike Hansen
> Nobody is jumping up and down volunteering to be release manager.
> In fact, I've repeatedly called for volunteers for a release manager,
> but there is nobody volunteering. I am concerned that adding a
> bunch of rules will make the release manager's job inflexible, more
> stressful, and less fun, and less likely to be something a volunteer
> would do.
I'll start doing sage-4.4.4 tomorrow morning. The main goal will be
getting the combinat tickets in.
--Mike
William Stein
Thanks!!!!!!!!!!!!
William
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
Robert Bradshaw
>>> Good to hear, though I think the audience is quite limited (there
>>> seems to be a very small minority that feels uncomfortable with the
>>> current procedure). :)
>
>> Some questions I think we should get input on (perhaps in a more
>> general
>> forum) is
>>
>> 1) What is the role of a release manager?
>> 2) What does a release manager have to do for each release?
>> 3) What in (2) could not be automated?
>
> [...]
>
> Nobody is jumping up and down volunteering to be release manager.
> In fact, I've repeatedly called for volunteers for a release manager,
> but there is nobody volunteering.
I'll volunteer right now, but it'll have to be for a later release as
I'm going to be on the road for the next couple of weeks so wouldn't
be able to do it until July. (Hopefully someone steps in between now
and then).
> I am concerned that adding a
> bunch of rules will make the release manager's job inflexible, more
> stressful, and less fun, and less likely to be something a volunteer
> would do.
I think a checklist has made people more willing to volunteer (though
not enough).
To clarify, the intent of my questions was to try and see what of the
release managers task we could offload to either referees or a script,
and when thinking about that I realized that "the release managers
task" is a fuzzy concept for me. If the job is just to take the
previous release and merge in the maximum number of positively
reviewed tickets that pass on a specific set of machines, that could
be done mechanically with little intervention (perhaps not right now,
but in the long run).
> The process by which releases are made should be determined by the
> release manager. They should be given a lot of flexibility to try
> whatever they want. A useful discussion might be about tools we can
> provide the release manager to make their job funner and easier.
>
> Right now, somebody could be merging patches and putting together
> sage-4.4.4. There's a brand spanking new clean sage-4.4.3 to start
> with:
>
> http://sage.math.washington.edu/home/wstein/build/release/4.4.3/sage-4.4.3.tar
>
> There are a *record* 99 tickets with positive review right here
> waiting to be merged:
>
> http://trac.sagemath.org/sage_trac/report/32
>
> But nobody is working on this. That is the real question we
> should be worrying about.
For sure, which is what I'm trying to get at.
- Robert
Nicolas M. Thiery
> On Fri, Jun 4, 2010 at 10:26 PM, Mike Hansen <mha...@gmail.com> wrote:
> > On Fri, Jun 4, 2010 at 10:16 PM, William Stein <wst...@gmail.com> wrote:
> >> Nobody is jumping up and down volunteering to be release manager.
> >> In fact, I've repeatedly called for volunteers for a release manager,
> >> but there is nobody volunteering. � � I am concerned that adding a
> >> bunch of rules will make the release manager's job inflexible, more
> >> stressful, and less fun, and �less likely to be something a volunteer
> >> would do.
> >
> > I'll start doing sage-4.4.4 tomorrow morning. �The main goal will be
> > getting the combinat tickets in.
> >
> > --Mike
>
> Thanks!!!!!!!!!!!!
I can't agree more!
That news surely boosts us to get even more positively reviewed
patches ready to go in ASAP :-)
Cheers,
Nathann Cohen
We have a big stack of patches waiting to be merged which is really a
hassle. There is no way to write a patch which is not based on that
ones, and I delayed the writing of several additions just waiting for
those to be merged into Sage... Oh, and they are very nice additions
too :-)
I promise the next tickets shouldn't interfere with each other !!!
Nathann