bug wranglers
Burcin Erocal
Motivated by the call for the bug days, here is an idea to manage the
rapidly increasing number of "new" tickets on trac.
Many of the bugs on trac are
- duplicates,
- already fixed, which can be closed after adding a doctest or
- has not been seen by a developer who can fix it since keeping up
with all the new tickets on trac is very time consuming, and
possibly the problem was filed in the wrong category.
We might be able to overcome this with a "bug-wrangler" team, people
who volunteer to
- look at newly submitted tickets, notify the related developers, ask
for examples and test cases if the report doesn't provide them,
etc.
- every once in a while, go through the open tickets and see if
they were fixed in a recent release
(perhaps this won't be such a problem once the duplicates are
filtered properly)
I know some people already spend time doing some of this, but it's
impossible to fight with more than 2000 open tickets without an
organized effort.
Most linux distributions already use a similar approach. The issues are
first assigned to the bug-wrangler team, where the email address points
to a mailing list. Then someone takes the new ticket, and follows up
until the right developer gives feedback.
This would also be an easy way to consolidate duplicate tickets, even
if they are filed in different components. The members of the
bug-wrangler mailing list will be able to see the initial report for
every ticket, so they might recall a similar problem reported a few
days ago.
Another advantage is that the members of this team don't need to be
developers, or even know how to code. It is enough to be able to listen
to user requests and use trac.
This could also be a good starting point for people who want to get
into Sage development, since it provides an opportunity to look through
the library and become familiar with the internal structure of Sage.
Comments?
Cheers,
Burcin
maldun
I think this is a great Idea!
I'm short on time in the next months, but
If I'm free again, could help with this.
greez,
Stefan
Martin Albrecht
> who volunteer to
>
> - look at newly submitted tickets, notify the related developers, ask
> for examples and test cases if the report doesn't provide them,
> etc.
>
> - every once in a while, go through the open tickets and see if
> they were fixed in a recent release
> (perhaps this won't be such a problem once the duplicates are
> filtered properly)
>
> I know some people already spend time doing some of this, but it's
> impossible to fight with more than 2000 open tickets without an
> organized effort.
> Comments?
Hi,
as far as I can tell all attempts at something like this failed in the past.
One idea to avoid such a failure in the future would be to have an e-mail
address, say "bug-wrangler" which rotates where it forwards to. So for
example, one week I'd get these e-mails and it would be my responsibility to
deal with them, the next week it is automatically sent to the next person etc.
This is just a quick thought, so there might be many much better ideas to
address past failures.
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinr...@jabber.ccc.de
Dr. David Kirkby
> Hi,
>
> Motivated by the call for the bug days, here is an idea to manage the
> rapidly increasing number of "new" tickets on trac.
It is well known in industry that the cost to fix bugs increases rapidly as they
time to fix them is delayed. See for example
http://on-agile.blogspot.com/2006/12/hidden-cost-of-delaying-bug-fixes.html
It depends very much on the industry, but set of quoted values are:
$10 in Design phase
$100 in working code
$1,000 in released software
Of course, in open-source software cost can not be considered too much in
monetary terms (though clearly in this case a company are willing to pay to have
bugs fixed).
But if someone writes code with a bug, a second peson builds upon that buggy
code with their own code, it should be obvious that there is a lot to be gained
by fixing the bugs as soon as possible. But should not be allowed to linger on
for a long time.
I feel we should be putting higher priority on fixing the bugs sooner, and not
adding more features.
I recently wrote a very small shell script to automatically find bugs in Sage.
It was slow, as each test invoked Sage once. I should be able to speed that up
by a couple of orders of magnitude, by not starting a new instance of Sage
before each test. (I'm in the process of re-writing it in C).
I can't help but feel that some of these could be caught much earlier, with a
bit more consideration given to testing. Simply by trying your code with invalid
input will often show bugs.
sage: seed(1,2)
sage: seed(100,34)
sage: seed(1,2,3,4,5,6,7)
will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid
input to other commands will hang Sage, so the only answer is to kill the process.
I think the main problem is ignorance. Good software engineering techniques do
not form part of mathematics degrees, so most Sage developers are totally
ignorant of the issues. Then those motivated to find more information soon hit
the fact that books on this topic are not cheap. I have an 18-year old copy of
this book, which despite the complaints the 7th edition is out of date, I think
much of the material would be useful to Sage developers.
There's also plenty of books on software testing.
Perhaps when William assembles the team in Seattle, he could find the money to
buy each person a book on software testing. Buy each person a different book,
then hopefully Sage developers will able to independently review the material.
Perhaps they each write a Wiki page on what they though was the most important
things they learned from the book.
I believe any belief that having "bug hunt weeks" is a long term solution is
rather flawed. The issues should be tackled at an earlier stage.
Dave
Jan Groenewald
> I believe any belief that having "bug hunt weeks" is a long term
> solution is rather flawed. The issues should be tackled at an
> earlier stage.
Despite not being a sufficient solution, are they not nonetheless
necessary? Or at least helpful?
regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^
Jeroen Demeyer
> Hi
>
>> I believe any belief that having "bug hunt weeks" is a long term
>> solution is rather flawed. The issues should be tackled at an
>> earlier stage.
>
> Despite not being a sufficient solution, are they not nonetheless
> necessary? Or at least helpful?
To me, the idea of these bug hunt days certainly sounds good. I've
noticed during earlier Sage Days that putting developers physically
together is a very good thing. It massively speeds up development.
Jeroen.
Burcin Erocal
On Sun, 17 Oct 2010 01:35:01 +1100
Minh Nguyen <nguye...@gmail.com> wrote:
> On Sat, Oct 16, 2010 at 11:21 PM, Burcin Erocal <bur...@erocal.org>
> wrote:
> > We might be able to overcome this with a "bug-wrangler" team,
>
> I would have thought "weed-wrangler" or "pest-wrangler". You know,
> Sage and horticulture :-)
We should definitely find a better name.
I took the "bug-wrangler" name from the Gentoo project [1]. I'm sure
other projects use different names, though I'm not familiar with
anything else.
[1] http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
Apparently Ubuntu has a BugSquad [2].
[2] https://wiki.ubuntu.com/BugSquad
I prefer "squad" to "wrangler," so I suggest PestSquad or TracNinja. :)
Does anybody else have suggestions for a name?
> > people
> > who volunteer to
> >
> > - look at newly submitted tickets, notify the related developers,
> > ask for examples and test cases if the report doesn't provide them,
> > etc.
>
> Also make sure the newly created ticket has sufficient information to
> allow people to duplicate the bug. Things like linking to the original
> bug report, if it exists, on any of the Sage mailing lists, providing
> sample code to duplicate the bug (or weed or pest :-), make sure the
> newly created ticket is not a duplicate of an existing ticket, cross
> link tickets with that new ticket if possible.
Good suggestions. We should put these on a wiki page.
> > Another advantage is that the members of this team don't need to be
> > developers, or even know how to code. It is enough to be able to
> > listen to user requests and use trac.
> >
> > This could also be a good starting point for people who want to get
> > into Sage development, since it provides an opportunity to look
> > through the library and become familiar with the internal structure
> > of Sage.
>
> I support your proposal as it is another way to encourage more people
> to become familiar with the Sage library.
Thanks. As I said before, there are a few people who try to do this
already as time permits. I think it would just be easier on everyone if
we got organized.
So let's settle on a name and get started.
Cheers,
Burcin
Burcin Erocal
On Sun, 17 Oct 2010 12:42:26 +0100
Martin Albrecht <martinr...@googlemail.com> wrote:
> > We might be able to overcome this with a "bug-wrangler" team, people
> > who volunteer to
> >
> > - look at newly submitted tickets, notify the related developers,
> > ask for examples and test cases if the report doesn't provide them,
> > etc.
> >
> > - every once in a while, go through the open tickets and see if
> > they were fixed in a recent release
> > (perhaps this won't be such a problem once the duplicates are
> > filtered properly)
> >
> > I know some people already spend time doing some of this, but it's
> > impossible to fight with more than 2000 open tickets without an
> > organized effort.
> ...
> > Comments?
>
> as far as I can tell all attempts at something like this failed in
> the past. One idea to avoid such a failure in the future would be to
> have an e-mail address, say "bug-wrangler" which rotates where it
> forwards to. So for example, one week I'd get these e-mails and it
> would be my responsibility to deal with them, the next week it is
> automatically sent to the next person etc. This is just a quick
> thought, so there might be many much better ideas to address past
> failures.
I was thinking of setting up trac to send a notice to a mailing list
for each new issue. Then people interested in this effort can follow
this list and help out. Is this possible? Can someone familiar with the
trac set up comment?
IMHO, distributing work day by day, or weekly is still putting too much
load on one person. It should be enough if someone contributes to one
issue per day.
Perhaps we should come up with a locking mechanism, to prevent two
different people from trying to sort the same issue at the same time,
but it feels like too much organization at the beginning.
Cheers,
Burcin
Dr. David Kirkby
> Hi
>
>> I believe any belief that having "bug hunt weeks" is a long term
>> solution is rather flawed. The issues should be tackled at an
>> earlier stage.
>
> Despite not being a sufficient solution, are they not nonetheless
> necessary? Or at least helpful?
>
> regards,
> Jan
Yes, I think they would be useful. Periods of concentrated effort at fixing bugs
is a standard practice in professional software engineering.
In a similar way I feel "bug fix only releases" would be useful, where one
concentrates on removing bugs, and not adding features. That idea has however
been very much disliked by many people.
Given the lack of enthusiasm by many (including William) for my suggestions of
"bug-fix-only" releases, it will be interesting to see how many take William up
on attending the "Bug Days".
dave
Martin Albrecht
> for each new issue. Then people interested in this effort can follow
> this list and help out. Is this possible? Can someone familiar with the
> trac set up comment?
> IMHO, distributing work day by day, or weekly is still putting too much
> load on one person. It should be enough if someone contributes to one
> issue per day.
> Perhaps we should come up with a locking mechanism, to prevent two
> different people from trying to sort the same issue at the same time,
> but it feels like too much organization at the beginning.
My guess would be that we won't have the issue with locking very often (i.e.
too many people doing too much work) but with no one feeling responsible. I
guess for me your suggestion would turn out something like this:
1) I sign up to that mailing list since I feel a responsibility of
contributing to Sage in such a way
2) For the first few days or weeks I go through newly opened tickets as you
suggested.
3) Eventually, probably in some phase where I have less disposable time, I
give up on dealing with this e-mail since "somebody else will take care of
it".
Of course, the answer could just be to not do step 3, but I would assume that
it would happen to many of us. Being responsible for a week a time is
something more local or short-time which would make it easier for me to
commit.
To given an example of the workload here's the list of tickets created on the
15th. It seems 3-5 new tickets a day is the normal load:
* Ticket #10134 (Provide the enumeration of word morphisms from a range of
integers) created by slabbe
* Ticket #10133 (Make sure log(1) returns an Integer, not an int) created by
kcrisman
* Ticket #10132 (Differential Geometry via Sage) created by mikarm
I am working in the field of differential geometry (research and teaching) …
* Ticket #10131 (Add option to specifiy path for twistd's process ID (.pid)
file) created by cschwan
* Ticket #10130 (Revamp __hash__, __cmp__ and __richcmp__) created by roed
There are a number of confusing and non-optimal features of the way Sage …
Thus, as a rule of thumb we could say whoever is responsible for a day should
deal with five tickets old and new. This seems like about 1-2h of work which
seems doable to me.
Of course, if many people feel differently then we should choose a different
path.
Martin Albrecht
> Does anybody else have suggestions for a name?
"Since 2005 a crack commando unit of developers is blamed for bugs they didn't
commit. ... If you have a patch, if no-one else can help, and if you can e-
mail them, maybe you can ask the B-Team." or so ;)
Burcin Erocal
Martin Albrecht <martinr...@googlemail.com> wrote:
> > I prefer "squad" to "wrangler," so I suggest PestSquad or
> > TracNinja. :)
>
> > Does anybody else have suggestions for a name?
>
> "Since 2005 a crack commando unit of developers is blamed for bugs
> they didn't commit. ... If you have a patch, if no-one else can help,
> and if you can e- mail them, maybe you can ask the B-Team." or so ;)
Perfect! I vote +1 for B-Team.
Shall we start calling you Hannibal? Are you setting up the mailing
list?
Cheers,
Burcin
P.S. I hope the name B-team doesn't mean that there will be only 4
members.
P.P.S. mabshoff would have made a mean B.A. :)
Jeroen Demeyer
> - look at newly submitted tickets, notify the related developers
Mike Witt
> In a similar way I feel "bug fix only releases" would be useful,
> where one concentrates on removing bugs, and not adding features.
> That idea has however been very much disliked by many people.
I believe that there are many people, who are not heard from, since they
are not on these lists, who might become sage users if a way could be
found to address this problem. I personally have been burned enough
times
now by obvious bugs that have shown up when I try to demonstrate what
I'm doing in sage, that I hesitate now to shares things readily.
-Mike
Jason Grout
(just answering the question about bug days, but I don't have time right
now to comment on the other points) We have already had several bug days
(week-long get-togethers; at least two that I've attended), plus
numerous 1-day meet-on-IRC bug days, and they have been very successful.
Jason
Robert Bradshaw
Though in an ideal world, this kind of thing wouldn't crash Sage, I'm
more worried about the kinds of bugs where valid input causes a
segfault, or, much worse, an incorrect answer.
> I think the main problem is ignorance. Good software engineering techniques
> do not form part of mathematics degrees, so most Sage developers are totally
> ignorant of the issues. Then those motivated to find more information soon
> hit the fact that books on this topic are not cheap. I have an 18-year old
> copy of this book, which despite the complaints the 7th edition is out of
> date, I think much of the material would be useful to Sage developers.
>
> http://www.amazon.com/Software-Engineering-Practitioners-Approach-International/dp/0071267824/ref=sr_1_1?ie=UTF8&s=books&qid=1287322048&sr=1-1
>
> There's also plenty of books on software testing.
>
> http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=software+testing&x=0&y=0
>
>
> Perhaps when William assembles the team in Seattle, he could find the money
> to buy each person a book on software testing. Buy each person a different
> book, then hopefully Sage developers will able to independently review the
> material. Perhaps they each write a Wiki page on what they though was the
> most important things they learned from the book.
I would submit that practicing good software engineering techniques is
more than a matter of finding the money (and especially time) to read
a good book on it--we all have different priorities on what we can
afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't
be useful for all of us to learn these things, just that I don't
expect working mathematicians to all find enough time on the side to
become expert software developers as well).
On a more practical note, I think it may help things if we actually
used the priority field. Certainly
Blocker: 14
Critical: 68
Major: 1609
Minor: 516
Trivial: 26
Is not the correct distribution. We have an extremely large number of
components of varying scope as well, this could probably use some
unification and cleanup as well.
In terms of bug-fix-only releases, I don't think anyone would object
to someone volunteering to do one (as long as the process didn't drag
out longer than a normal release).
- Robert
kcrisman
> I would submit that practicing good software engineering techniques is
> more than a matter of finding the money (and especially time) to read
> a good book on it--we all have different priorities on what we can
> afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't
> be useful for all of us to learn these things, just that I don't
> expect working mathematicians to all find enough time on the side to
> become expert software developers as well).
> On a more practical note, I think it may help things if we actually
> used the priority field. Certainly
>
> Blocker: 14
> Critical: 68
> Major: 1609
> Minor: 516
> Trivial: 26
>
> Is not the correct distribution. We have an extremely large number of
> components of varying scope as well, this could probably use some
> unification and cleanup as well.
regular basis. And most of the 'critical' ones are not critical in
that sense. But there hasn't been much discussion at all of what
counts as a critical or major thing - it's mostly in the eye of the
beholder.
- kcrisman
Donald Alan Morrison
On Oct 16, 5:21 am, Burcin Erocal <bur...@erocal.org> wrote:
>[...]
> bug-wrangler mailing list will be able to see the initial report for
> every ticket, so they might recall a similar problem reported a few
> days ago.
>
> Another advantage is that the members of this team don't need to be
> developers, or even know how to code. It is enough to be able to listen
> to user requests and use trac.
>
> This could also be a good starting point for people who want to get
> into Sage development, since it provides an opportunity to look through
> the library and become familiar with the internal structure of Sage.
>
> Comments?
(and party) after the (bug) funeral?
Dr David Kirkby
On 18 Oct, 21:33, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby
> > sage: seed(100,34)
> > sage: seed(1,2,3,4,5,6,7)
>
> > will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid
> > input to other commands will hang Sage, so the only answer is to kill the
> > process.
>
> Though in an ideal world, this kind of thing wouldn't crash Sage, I'm
> more worried about the kinds of bugs where valid input causes a
> segfault, or, much worse, an incorrect answer.
especially if the results look believable. If you try to factorise an
integer and get a Bessel function as an answer, it is obviously wrong.
Some results look reasonable and so are very bad news.
I'd also agree getting crashes with valid input is bad, but its a fact
of life people do enter invalid input. Sometimes how one uses a
function is not very obvious, so using invalid input is going to
happen. If that crashes Sage, and stops lots of people working on a
Sage server, I think that's pretty serious, though not as bad as
incorrect results.
> > I think the main problem is ignorance. Good software engineering techniques
> > do not form part of mathematics degrees, so most Sage developers are totally
> > ignorant of the issues. Then those motivated to find more information soon
> > hit the fact that books on this topic are not cheap. I have an 18-year old
> > copy of this book, which despite the complaints the 7th edition is out of
> > date, I think much of the material would be useful to Sage developers.
>
> > There's also plenty of books on software testing.
>
> > Perhaps when William assembles the team in Seattle, he could find the money
> > to buy each person a book on software testing. Buy each person a different
> > book, then hopefully Sage developers will able to independently review the
> > material. Perhaps they each write a Wiki page on what they though was the
> > most important things they learned from the book.
>
> I would submit that practicing good software engineering techniques is
> more than a matter of finding the money (and especially time) to read
> a good book on it--we all have different priorities on what we can
> afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't
> be useful for all of us to learn these things, just that I don't
> expect working mathematicians to all find enough time on the side to
> become expert software developers as well).
IMHO, if Sage is every to become a viable alternative to Maple,
Mathematica or MATLAB, then practicing good software engineering is an
absolute *must* - not an option. (I purposely excluded Magma from that
list, as I know nothing about that tool).
If you believe that levels of quality equal to those three commercial
packages can be achieved without such skills, then we will have to
agree to differ. Of course, for some users Sage is no doubt already
the best of these packages, but it is unlikely to be so for a mass
audience without major changes.
I was not suggesting anyone spend 10,000 hours studying the subject of
software engeering. I'm not suggesting people need to be experts. But
perhaps spending 20-50 hours on it is not unreasonable. I don't know
about you, but I've probably devoted 1000 hours to working on Sage, so
20-50 is a small percentage. I think 20-50 hours would be for you
too.
It's a fact of life that you often have to learn new skills. 20-50
hours would not mean taking a week off of work, but reading a book on
a train to work, or at night instead of a bit of TV. Expecting a new
developer to spend such time would be unreasonable, but then their
contributions should in my opinion come under closer scrutiny from
those with better knowledge.
Mike Witt said above, with reference to the Sage bugs:
"I personally have been burned enough times now by obvious bugs that
have shown up when I try to demonstrate what
I'm doing in sage, that I hesitate now to shares things readily."
working. I certainly would not hesitate to show people things with
MATLAB or Mathematica. If one of these tools did crash, I would not
have egg on my face. But with Sage I would.
Currently one person with poor Python skills can review the work of
another with poor Python skills, and the code get committed to Sage.
There's little filtering.
I know Kcrisman has said +1 to your comments, so I'd say I'd have to
disagree with him too.
> On a more practical note, I think it may help things if we actually
> used the priority field. Certainly
> Blocker: 14
> Critical: 68
> Major: 1609
> Minor: 516
> Trivial: 26
time the "algebra" component. That's what I added a new category
"PLEASE CHANGE". Likewise the default "type" is now "PLEASE CHANGE"
and not "defect".
Actually, if one was to take the time to read about the topic of
software quality control, one would discover that setting priority
like we do is far from optimal. It would be better to have a formula,
something like:
priority=f(Severity, Impact, Visibility, Class)
http://software-quality.blogspot.com/2005/09/bug-priority-and-severity.html
http://knol.google.com/k/setting-bug-severity-and-priority#
http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspx
Dave
Mike Hansen
> If that crashes Sage, and stops lots of people working on a
> Sage server, I think that's pretty serious, though not as bad as
> incorrect results.
It only crashes that one user's session. Each worksheet is run in a
different process.
--Mike
kcrisman
> I was not suggesting anyone spend 10,000 hours studying the subject of
> software engeering. I'm not suggesting people need to be experts. But
> perhaps spending 20-50 hours on it is not unreasonable. I don't know
> about you, but I've probably devoted 1000 hours to working on Sage, so
> 20-50 is a small percentage. I think 20-50 hours would be for you
> too.
that it would be particularly effective to spend 20-50 hours reading
books about this. Software seems to be one of those things that is
hard to really learn how to do without actually doing it. 10-20
hours spent trying to do some Sage development, but with a couple
quality software engineers looking over your shoulder the whole time,
might do it. The idea of having one piece of a Sage days devoted to
people sharing ideas from books they read in a coordinated way sounds
plausible as well, though probably it would really depend on the Sage
days in question.
> "I personally have been burned enough times now by obvious bugs that
> have shown up when I try to demonstrate what
> I'm doing in sage, that I hesitate now to shares things readily."
Sage, of course.
> Currently one person with poor Python skills can review the work of
> another with poor Python skills, and the code get committed to Sage.
> There's little filtering.
I often find that people who contact us (and even contact me
personally) about this are more likely to not want to contribute
*anything*, even very minor bugfixes or documentation improvements,
because they are not confident in their skills. Most people who feel
confident enough to review are confident enough to point out things
that look bad, and those who don't still will often point out
something wrong/suboptimal.
What happens more often, I think, is that someone with decent/good
Python skills is tired or lackadaisical and reviews something they
want to get in without spending the 1+ hours it takes to really test
edge cases and so forth of a patch also written by someone with decent/
good Python skills who is tired or lackadaisical... etc. Since such
a person also contributes and reviews in quality ways most of the
time, it's much harder to filter for that.
Finally, I think that MANY of the new bugs in Sage are *not* a result
of someone destroying old code, but rather of a bug appearing where
before there was no functionality! I think that to most Sage
developers, it is better to have 99 out of 100 cases give the right
answer, and have it tested out and hopefully fix the bug soon that
surely is there, than to have a NotImplementedError for years and
years. Stagnation is the way to not attract the new developers we
would need (for time's sake) to improve our software engineering
practice, indeed.
To be sure, this is a design decision of sorts, and one at odds with
your books, perhaps. But unless we also can operate under the
implicit assumptions of them (which probably include things like
actual employers, or perhaps a pool of developers who all have similar
skill sets - neither of which is the case here, in a project which is
monstrously diverse in terms of skill needs and obviously very non-
hierarchical), I don't see how it's feasible to implement your ideas
on this, other than the reminders of good practice you give in public
fora such as this and on Trac tickets. Which I think that is having a
positive impact, incidentally!
:)
- kcrisman
Dr. David Kirkby
>
>> I was not suggesting anyone spend 10,000 hours studying the subject of
>> software engeering. I'm not suggesting people need to be experts. But
>> perhaps spending 20-50 hours on it is not unreasonable. I don't know
>> about you, but I've probably devoted 1000 hours to working on Sage, so
>> 20-50 is a small percentage. I think 20-50 hours would be for you
>> too.
>
> It's not clear to me that without a specific time and place to do so,
> that it would be particularly effective to spend 20-50 hours reading
> books about this.
I don't have much experience to say whether you are right or wrong. I do *not*
have a software background. I have never done any sort of computer science degree.
However, I had had to write code which others will use, and it became clear to
me that on a large project one needs to do a bit more than just writing the
code. Based on my experience, I feel that 20-50 hours reading about what are
good software engineering practices would be useful. Those are just as relevant
if you code in C, assembler, Python or foobar.
> Software seems to be one of those things that is
> hard to really learn how to do without actually doing it.
My main point was not about the code one writes.
Clearly if you write in Python you should know about Python, but that's another
matter altogether. I tend to agree that one of of the best ways to learn a
language, is to use it.
Things that I believe would be good for Sage, and one could get some useful
understanding in 20-50 hours from a software engineering book would be:
* An understanding of how software projects should be managed. This is
especially so for William of course, but in general I think that's useful to
know for all of us. To a certain extent, some trac tickets have to be "managed".
* An understanding of why bugs should be fixed as early as possible.
* Understanding the different sorts of tests that software developers use -
black box testing, white box testing etc.
* Automated testing tools.
* Understanding ways to estimate the quality of code. At the moment there is no
analysis of defect rates in Sage.
* The life-cycle of software. Analysis -> Design -> Code -> Test -> Maintenence.
This applies to Sage as a whole, but also to individual parts of Sage.
* An understanding of why software wears out. What can we do to reduce the rate
of wearout?
> 10-20
> hours spent trying to do some Sage development, but with a couple
> quality software engineers looking over your shoulder the whole time,
> might do it.
That's an entirely different thing - I'm not talking about that. Any course on
software engineering is not likely to have you writing code with someone looking
over your shoulder.
> The idea of having one piece of a Sage days devoted to
> people sharing ideas from books they read in a coordinated way sounds
> plausible as well, though probably it would really depend on the Sage
> days in question.
That would sound good. If each person read a chapter of a book on a topic, and
gave a short talk to everyone else, it should at least make people aware of the
other issues.
I bought this book
though I'm not over-impressed with it.
Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book
to be very useful.
You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon.
> To be sure, this is a design decision of sorts, and one at odds with
> your books, perhaps. But unless we also can operate under the
> implicit assumptions of them (which probably include things like
> actual employers, or perhaps a pool of developers who all have similar
> skill sets - neither of which is the case here, in a project which is
> monstrously diverse in terms of skill needs and obviously very non-
> hierarchical), I don't see how it's feasible to implement your ideas
> on this, other than the reminders of good practice you give in public
> fora such as this and on Trac tickets. Which I think that is having a
> positive impact, incidentally!
>
> :)
>
> - kcrisman
The fact people have different skill sets, the fact we are not employed, the
fact there is essentially non-hierarchical, does not really change things too
much. Some aspects obviously do, as you can't demand people do what you want
when you don't pay them. But hopefully people more people would do things better
if they were aware of good practices.
Dave
Martin Albrecht
> > people sharing ideas from books they read in a coordinated way sounds
> > plausible as well, though probably it would really depend on the Sage
> > days in question.
>
> That would sound good. If each person read a chapter of a book on a topic,
> and gave a short talk to everyone else, it should at least make people
> aware of the other issues.
>
> I bought this book
>
> http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013703515
> 2/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1
>
> though I'm not over-impressed with it.
>
> Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
> this book
>
> http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/
> 0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4
>
> to be very useful.
>
> You can pick up a used copy of the 6th edition (2004) for less than $2 on
> Amazon.
I'd like to return to Burcin's original proposal if possible. He made a
*concrete* proposal for what to do with the growing number of bugs in Sage and
somehow this turned into a threat discussing which books on Software
Engineering we should read and how early one should should fix bugs.
Don't get me wrong, this is a useful discussion to be had but it is a shame
that discussions move from concrete to abstract instead of the other way
around quite often these days ([sage-general] anyone? :))
It seems clear to me even if we do employ all kinds of software engineering
techniques that there will still be bugs we'll have to tackle and our current
approach as serious issues. Even OpenBSD has bugs which they have to address
despite the fact that they make quite an effort to scrutinize code.
To get back to Burcin's proposal it seems while there is some support, it
doesn't seem to spur enough interests to have enough people to distribute the
load to or am I mistaken?
Cheers,
Dr. David Kirkby
>>> The idea of having one piece of a Sage days devoted to
>>> people sharing ideas from books they read in a coordinated way sounds
>>> plausible as well, though probably it would really depend on the Sage
>>> days in question.
>>
>> That would sound good. If each person read a chapter of a book on a topic,
>> and gave a short talk to everyone else, it should at least make people
>> aware of the other issues.
>>
>> I bought this book
>>
>> http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013703515
>> 2/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1
>>
>> though I'm not over-impressed with it.
>>
>> Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
>> this book
>>
>> http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/
>> 0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4
>>
>> to be very useful.
>>
>> You can pick up a used copy of the 6th edition (2004) for less than $2 on
>> Amazon.
>
> I'd like to return to Burcin's original proposal if possible.
It might have been better to post the followup to his comments not mine, but it
does not matter too much.
> He made a
> *concrete* proposal for what to do with the growing number of bugs in Sage and
> somehow this turned into a threat discussing which books on Software
> Engineering we should read and how early one should should fix bugs.
First, without any quantitative data, are we sure the number is growing? We
should consider Sage is growing, adding new functionality, so an increase in the
absolute number of bugs is inevitable. My gut feeling is the situation is
getting "worst", but I've seen no evidence to prove this.
Even the most basic graph (say number of bugs vs date), would be semi-useful.
There are methods of measuring software quality
http://en.wikipedia.org/wiki/Software_quality
http://www.developer.com/tech/article.php/3644656/Software-Quality-Metrics.htm
http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics
but we don't do any of them. Ultimately the best way to manage the situation it
to measure it, and determine the effect of various changes.
Like it or not, the situation does need to be managed - it won't solve itself.
You can see where I am leading with this - back to applying software engineering
principles!
> Don't get me wrong, this is a useful discussion to be had but it is a shame
> that discussions move from concrete to abstract instead of the other way
> around quite often these days ([sage-general] anyone? :))
I would not consider my comments abstract, but individual book recommendations
are less relevant to what Burcin said.
> It seems clear to me even if we do employ all kinds of software engineering
> techniques that there will still be bugs we'll have to tackle and our current
> approach as serious issues. Even OpenBSD has bugs which they have to address
> despite the fact that they make quite an effort to scrutinize code.
> To get back to Burcin's proposal it seems while there is some support, it
> doesn't seem to spur enough interests to have enough people to distribute the
> load to or am I mistaken?
To make matters easier to follow, lets look at Burcin's proposals.
http://groups.google.com/group/sage-devel/msg/40d2af34d86586de?hl=en
and consider them, here in an abbreviated and expanded form.
1) Burcin said: "Many of the bugs on trac are duplicates and could be closed."
He is probably right. Some are undoubably wrongly categorised, but from a
personal perspective I often don't have a clue what to file them under anyway.
Perhaps for those of us without maths degrees, the categories could be more
explicit. But even that is not a full solution.
I've got a reasonable understanding about random numbers, as I did quite a bit
of work on it during my Ph.D with Monte Carlo modelling. But I don't really have
a clue what to file #10113 under.
Often bugs should really be in several categories, but one can only chose one.
IMHO it should be a tick-box, not a pull-down. If something with an elliptic
curve causes a doctest failure, on Solaris, do I file it under
* Elliptic curves ?
* Doctests ?
* Solaris ?
If person X files such a report, John Cremola might be in the best position to
fix it, but then I'd probably be able to make comments too. People with
knowledge about doctests might realise its actually a failure in the doctest.
(I'm very untrusting of the doctesing framework, especially for parallel tests).
2) Burcin said: "We might be able to overcome this with a "bug-wrangler" team,
people who volunteer to ..."
IMHO, If the categories could with a tick box, then this step could hopefully be
removed for future bugs. The right people will automatically be notified. We
need however to have a category "I need helping chosing the right categories".
That would be especially useful for those of us with a non-maths background, but
I think to others too, as parts of Sage are so specialised, I doubt I'm the only
one who struggles to know what to categorise things under.
I think the lack of too many "sign me up to do this" shows there's not likely to
be the number of developers taking this on. They might be more attracted to do
it if they realise that it only needs to be done once, and new bugs would
automatically be assigned to the right person.
Even if you understand what the bug is, the chances are you don't know who is
the best person to look at the bug.
Several categories have nobody at all assigned to them. Since I'm an admin on
trac I can see this. These include:
* cygwin
* debian-package
* distribution
* dsage
* experimental package
* factorization (this one *really* surprises me)
* msvc
* optional packages
* packages
* performance
* PLEASE CHANGE
* relocation
* c_lib is assigned to "tba". I'm not sure if that's a real user, or just
mis-named from "tbd". If so, that's another one with nobody assigned to it.
Many have only William assigned to them, but he is concentrating more on Psage now.
Not to be overly pessimistic, but one metric we do not collect, but Google do
for us, is the number of posts each month to sage-devel. There has been a very
dramatic falloff this year compared to all other years.
http://groups.google.com/group/sage-devel/about?hl=en
Every month except January has had less posts than the same month last year, and
that fraction is declining rapidly. Last month see only 37% of the posts
compared to September 2009.
The same is true for sage-support
http://groups.google.com/group/sage-support/about?hl=en
I think the number of posts to sage-support is more worrying than to sage-devel,
but I believe the combination rather shows that we are unlikely to find a lot of
developers taking on Burcin's proposals.
> Cheers,
> Martin
Dave
Johan S. R. Nielsen
should definitely move towards more structure, documentation, testing
and other software engineering practices, but as for any Open Source-
project, these things should come naturally as the project grows and
matures; as has already happened with Sage a lot, it seems (for a
relative new-comer like me). To require too much too soon would kill
the joy of working on the project and thus kill the project itself.
Burcin's suggestion seem to fit this curve pretty well at this time.
New developers and bugfixers -- with little overview of the monster
that is Sage -- would feel more confident in reporting and fixing bugs
if there was a feeling that there was someone (or a group of someones)
with overview and structure. If some enthusiastic veterans could be
found and agree on the exact model of this, I think it would improve
bug-tracking and -fixing in a number of ways:
- overview of bugs, their severity and class (by cleaning up,
removing duplicates, collating related tracs, and reclassifying)
- better classification of bugs by everyone else (by monkey-see-
monkey-do)
- better overview over bugs to fix before releases (by better
overview over all bugs)
- shorter pickup-time between a trac has been filed (possibly by
someone not interested in fixing it) and someone is looking at it
- assurance that a veteran has looked at the trac, accepted it, and
maybe even given an approving nod after positive review
- and all of this gives more confidence to developer-rookies
I think the system should entirely superseed the automatic-owner
system that is currently in Sage. Software-speaking, this would
provide an abstract interface between the tracs and those responsible
for it, which makes it more flexible to have either one, several or
many owners of a trac or class of tracs.
Personally, I like the one-week-at-a-time suggestion (though several
people should be on duty each week perhaps) sounds best. However, it's
easy for me to say, as I don't think I have the required experience to
undertake this duty ("You are not bug-ninja materiAL, SOLDIER! Drop
down and give me a recursive function generating the Fibonacci
sequence!"). When and if the time comes, I would be happiest with a
one-week-at-a-time schedule, though.
> Burcin wrote:
> Perhaps we should come up with a locking mechanism, to prevent two
> different people from trying to sort the same issue at the same time,
> but it feels like too much organization at the beginning.
but surely a mechanism so that a bug-wrangler could see that no other
bug-wrangler has already looked at this new trac.
Cheers,
Johan
On Oct 20, 11:37 am, Martin Albrecht <martinralbre...@googlemail.com>
wrote:
> > > people sharing ideas from books they read in a coordinated way sounds
> > > plausible as well, though probably it would really depend on the Sage
> > > days in question.
>
> > That would sound good. If each person read a chapter of a book on a topic,
> > and gave a short talk to everyone else, it should at least make people
> > aware of the other issues.
>
> > I bought this book
>
>
> > though I'm not over-impressed with it.
>
> > Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
> > this book
>
Johan S. R. Nielsen
> > > people sharing ideas from books they read in a coordinated way sounds
> > > plausible as well, though probably it would really depend on the Sage
> > > days in question.
>
> > That would sound good. If each person read a chapter of a book on a topic,
> > and gave a short talk to everyone else, it should at least make people
> > aware of the other issues.
>
> > I bought this book
>
>
> > though I'm not over-impressed with it.
>
> > Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
> > this book
>
kcrisman
>
> Often bugs should really be in several categories, but one can only chose one.
> IMHO it should be a tick-box, not a pull-down. If something with an elliptic
a lot of problems. Likewise, it would be nice to be able to be
notified automatically about tickets in certain areas, without being
an "owner". Even if this is possible, it's not obvious how to do it.
> Not to be overly pessimistic, but one metric we do not collect, but Google do
> for us, is the number of posts each month to sage-devel. There has been a very
> dramatic falloff this year compared to all other years.
>
> http://groups.google.com/group/sage-devel/about?hl=en
> I think the number of posts to sage-support is more worrying than to sage-devel,
> but I believe the combination rather shows that we are unlikely to find a lot of
> developers taking on Burcin's proposals.
might), but it is interesting. Thanks for that.
- kcrisman
William Stein
I take it to mean that Sage is now a mature project with roughly the
right number of developers. That said, everybody should keep
recruiting new people as aggressively as they can, since developers
come and *go*, as they have children, have to finish a thesis, get
involved in other projects, finish making the contributions to sage
they find interesting, etc.
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Dr. David Kirkby
>
>
>>
>> Often bugs should really be in several categories, but one can only chose one.
>> IMHO it should be a tick-box, not a pull-down. If something with an elliptic
>
> I didn't know this was possible on Trac; certainly this would overcome
> a lot of problems. Likewise, it would be nice to be able to be
> notified automatically about tickets in certain areas, without being
> an "owner". Even if this is possible, it's not obvious how to do it.
I don't know if it's possible. It would seem a sensible feature, and perhaps one
can do it in the latest version. It was just an observation that it would be
useful.
I've just registered on the 'trac' mailing list, and asked if this is possible.
But since it's a moderated list, my post has not appeared yet, so I can't
provide a link.
If it was possible to set this up it would be good. It seems such an obvious
thing to have to me. If it's not possible, perhaps I can file an RFE.
Dave
Robert Bradshaw
<J.S.R....@mat.dtu.dk> wrote:
> I think that Burcin's suggestion is excellent. Development of Sage
> should definitely move towards more structure, documentation, testing
> and other software engineering practices, but as for any Open Source-
> project, these things should come naturally as the project grows and
> matures; as has already happened with Sage a lot, it seems (for a
> relative new-comer like me). To require too much too soon would kill
> the joy of working on the project and thus kill the project itself.
+1 I have definitely seen that the level of bureaucracy has going up,
especially in the last year or two, has turned off a lot of potential
and even former developers. The focus on software engineering and
testing can certainly be good for quality (though that's not an
immediate or certain implication), but the problem is that too much
emphasis on it has a significant chilling effect on contributions. The
lag time between hacking out some code and getting it in is way too
high these days discourages contribution and sucks up a lot of
development time and energy with endless rebases and waiting. And
though we all want to produce bug-free code, holding that up as the
primary objetive (as opposed to producing useful code) I think
dissuades people from submitting or refereeing code.
I'm not sure I have a solution, but one thing that keeps coming to
mind is that Sage is trying to span several audiences with different
goals and criteria, and perhaps the various audiences would be best
met by a stable vs. unstable model like Debian. Purple sage is an
extreem move in this direction (more like Debian experimental)--I can
certainly see the attraction and value, but I just hope it doesn't
become an incompatible fork.
I agree that a big part of the problem is that it's hard to get a big
picture of all the bugs being worked on. The idea of a weekly
"bug-wrangler" is an interesting one. I have a simpler proposal (which
may be insufficient, but would complement a bug-wrangler's role and is
much easier to implement).
First, have the initial status of tickets be some pre-new stage.
(Something like "unclassified".) This woud make it so you don't have
to be an expert to classify a bug. Volunteers could go and look at all
unclassified tickets and file them appropriately (severity, defect vs.
enhancement, component, duplicate, etc.) Of course, there could be a
rotating bug-wrangler, but if it was easy enough for a "veteran" to
hop on and categorize a bunch of them in one sitting this might not
even be necessary.
Second, rather than have the default milestone be the next release,
have some default future milestone. Only tickets that are actively
being worked on get put on the current release. This would make it
much easier to see what's being worked on (or at least cared about)
and what to expect in the next release. Sufficiently important items
(blockers) would also get added here.
Thirdly, I think the list of components could be cleaned up.
All of these would help us get a better picture of the overall state
of Sage. Finally, we need more automation. Refereeing code shouldn't
have to involve downloading and applying patches and running all
tests--that should all be done automatically (with failing tickets
bounced right away, or at least in a 24-48 hour window). We should
have a notebook server with sessions of Sage with various tickets
already applied for quick refereeing (or a CLI interface on, say,
boxen for those who prefer that--"telnet/ssh
10921.sage.math.washington.edu" would be cool, opening you immediately
into a jailed sage session). I'll plug
http://trac.sagemath.org/sage_trac/ticket/9967 which is a requirement
for this and I just recently started to write a per-ticket build bot.
This would help close the gap and lag between writing code and getting
it into Sage, and I think that having such a small gap was one of the
key ingredients in letting Sage explode like it did.
- Robert
William Stein
<robe...@math.washington.edu> wrote:
> On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen
> <J.S.R....@mat.dtu.dk> wrote:
>> I think that Burcin's suggestion is excellent. Development of Sage
>> should definitely move towards more structure, documentation, testing
>> and other software engineering practices, but as for any Open Source-
>> project, these things should come naturally as the project grows and
>> matures; as has already happened with Sage a lot, it seems (for a
>> relative new-comer like me). To require too much too soon would kill
>> the joy of working on the project and thus kill the project itself.
>
> +1 I have definitely seen that the level of bureaucracy has going up,
> especially in the last year or two, has turned off a lot of potential
> and even former developers.
Another +1. The level of bureaucracy has gone up so much in the last
year that it has very seriously turned off me.
> The focus on software engineering and
> testing can certainly be good for quality (though that's not an
> immediate or certain implication), but the problem is that too much
> emphasis on it has a significant chilling effect on contributions. The
> lag time between hacking out some code and getting it in is way too
> high these days discourages contribution and sucks up a lot of
> development time and energy with endless rebases and waiting.
+1
It kills a large portion of potential contributions of code for
advanced research, perhaps 80% or more. I've talked to sooooo many
people about this in the last few months...
> And
> though we all want to produce bug-free code, holding that up as the
> primary objetive (as opposed to producing useful code) I think
> dissuades people from submitting or refereeing code.
Also, anybody who has significant experience with software engineering
knows that producing bug-free code is a recipe for producing almost no
code.
I was talking to somebody today who works on Microsoft Windows
(actually implementing the OS there), and who has also written a lot
of code for Sage (at a "research level" -- advanced number theory
stuff). He said internally at Microsoft code gets into the system,
and out getting used by a lot of people (internally) much more quickly
than with Sage. Instead of the very "all or nothing" model that we
tend to have, they have many levels of review that code goes through.
Sage would benefit from something similar. That's basically what
http://purple.sagemath.org/ is about: a way to get code out there and
distributed, used, etc., but without all the bureaucracy. As an
example, I'll sit down this coming Tuesday with Sal Baig, and get his
and Chris Hall's library for computing with elliptic curves over
function fields into PSAGE, and have it be in the next release.
That's code that isn't stable yet and is mainly for research. For a
year they have been trying to get it into Sage, but it just isn't
happening, since they care and know much more about *using* the code
for research purposes, than about how to make a proper
makefile/autoconf setup, so it builds fine on Solaris and OS X 10.4.
I think PSAGE will show that the increasingly bureaucratic and
plodding way in which code gets into Sage isn't necessarily bad, in
the same sense that Debian can be very plodding and bureaucratic, but
it still provides a good foundation for many other much more svelte
and useful Linux distributions.
> I'm not sure I have a solution, but one thing that keeps coming to
> mind is that Sage is trying to span several audiences with different
> goals and criteria, and perhaps the various audiences would be best
> met by a stable vs. unstable model like Debian. Purple sage is an
> extreem move in this direction (more like Debian experimental)--I can
> certainly see the attraction and value, but I just hope it doesn't
> become an incompatible fork.
A difference from debian experimental is that PSAGE starts by removing
over 20 standard packages from Sage. In fact, so far, that is
essentially *all* that PSAGE is. Also, my intention is that most
Python code in PSAGE go into a different Python module than the "sage"
one.
This is perhaps already provided by:
http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA
Harald Schilly could probably set things up so more people can wrangle the bugs
that come in through that page.
> Second, rather than have the default milestone be the next release,
> have some default future milestone.
There's no default milestone. See for yourself:
http://trac.sagemath.org/sage_trac/newticket
It being the next release is merely a social convention... That said,
of course you mean "instead of whatever is done now..."
>Only tickets that are actively
> being worked on get put on the current release. This would make it
> much easier to see what's being worked on (or at least cared about)
> and what to expect in the next release. Sufficiently important items
> (blockers) would also get added here.
Couldn't something like that be accomplished with a trac report
showing the 50 "most active" tickets? Sort of like how
http://ask.sagemath.org/questions/ by default shows the 50 most
active questions, and http://mathoverflow.net/ shows the top 50 or so
most active questions?
> Thirdly, I think the list of components could be cleaned up.
For the last year people kept asking to add new trac components (I
know, because I had to add them). There used to only be a handful.
Just out of curiosity, is trac still the best system to use for
managing what we're managing? You work at Google and they have their
own free http://code.google.com/ thing, which provides similar
capabilities to trac, but with integrated code review, the possibility
to delete comments (w00t!), etc., native support for Mercurial (which
trac barely supports, preferring SVN), easy forking, etc. I have so
far little experience with code.google.com, but I'm sort of curious
how good it is. I set it up for PSAGE here
http://code.google.com/p/purplesage/ since I didn't want to have to
manage a whole trac, hg repo, etc., yet again.
> All of these would help us get a better picture of the overall state
> of Sage. Finally, we need more automation. Refereeing code shouldn't
> have to involve downloading and applying patches and running all
> tests--that should all be done automatically (with failing tickets
> bounced right away, or at least in a 24-48 hour window). We should
> have a notebook server with sessions of Sage with various tickets
> already applied for quick refereeing (or a CLI interface on, say,
> boxen for those who prefer that--"telnet/ssh
> 10921.sage.math.washington.edu" would be cool, opening you immediately
> into a jailed sage session). I'll plug
> http://trac.sagemath.org/sage_trac/ticket/9967 which is a requirement
> for this and I just recently started to write a per-ticket build bot.
> This would help close the gap and lag between writing code and getting
> it into Sage, and I think that having such a small gap was one of the
> key ingredients in letting Sage explode like it did.
+1 You hit the nail on the head. The small gap absolutely *was* the
reason. I missed so many key things in (social and other) life
during the first 1.5 years of Sage in order to make the next releases,
because I knew how absolutely critical it was putting together new
releases in order to draw in developers and keep the momentum going.
Making a release 1 day earlier, literally made a huge difference
during that time. Many developers who got involved then, because of
the fast cycle, have since stopped working on Sage. Now the release
cycle is about 2 months between releases. You can see here (look at
the dates) what it used to be: http://sagemath.org/src-old/
Again, I'm not necessarily claiming Sage itself needs to move that
quickly again. This is very difficult technically due to the larger
number of platforms supported, the larger test suite, codebase, etc.
But something does need to change, or some of the truly brilliant
computational mathematics researchers (like Mark Watkins, say) will be
unlikely to be drawn in again. For me, PSAGE will accomplish this
goal, while allowing me to continue to benefit from the incredibly
valuable high quality work that so many people are doing on making
Sage a solid, well tested, cross-platform system.
Tom Boothby
> On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw
> <robe...@math.washington.edu> wrote:
>> On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen
>> <J.S.R....@mat.dtu.dk> wrote:
>>> I think that Burcin's suggestion is excellent. Development of Sage
>>> should definitely move towards more structure, documentation, testing
>>> and other software engineering practices, but as for any Open Source-
>>> project, these things should come naturally as the project grows and
>>> matures; as has already happened with Sage a lot, it seems (for a
>>> relative new-comer like me). To require too much too soon would kill
>>> the joy of working on the project and thus kill the project itself.
>>
>> +1 I have definitely seen that the level of bureaucracy has going up,
>> especially in the last year or two, has turned off a lot of potential
>> and even former developers.
>
> Another +1. The level of bureaucracy has gone up so much in the last
> year that it has very seriously turned off me.
+1, and me too.
>
>> The focus on software engineering and
>> testing can certainly be good for quality (though that's not an
>> immediate or certain implication), but the problem is that too much
>> emphasis on it has a significant chilling effect on contributions. The
>> lag time between hacking out some code and getting it in is way too
>> high these days discourages contribution and sucks up a lot of
>> development time and energy with endless rebases and waiting.
>
> +1
>
> It kills a large portion of potential contributions of code for
> advanced research, perhaps 80% or more. I've talked to sooooo many
> people about this in the last few months...
Yup.
>
>> And
>> though we all want to produce bug-free code, holding that up as the
>> primary objetive (as opposed to producing useful code) I think
>> dissuades people from submitting or refereeing code.
>
> Also, anybody who has significant experience with software engineering
> knows that producing bug-free code is a recipe for producing almost no
> code.
Agreed.
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Robert Bradshaw
Thus psage will be a superset of a subset of sage. Do you envision a
migration path of code from psage to sage? (Perhaps not instigated or
executed by the original authors of the code of course.) Would it be
easy to install the "missing pieces" into a psage setup, or,
conversely, install the new parts of psage on top of Sage? That being
said, the sage-combinat model seems like it would be a huge amount of
work to manage, but is nice for the end user. (Doesn't solve the
messiness of ugly build problems with arcane spkgs...)
>> First, have the initial status of tickets be some pre-new stage.
>> (Something like "unclassified".) This woud make it so you don't have
>> to be an expert to classify a bug. Volunteers could go and look at all
>> unclassified tickets and file them appropriately (severity, defect vs.
>> enhancement, component, duplicate, etc.) Of course, there could be a
>> rotating bug-wrangler, but if it was easy enough for a "veteran" to
>> hop on and categorize a bunch of them in one sitting this might not
>> even be necessary.
>
> This is perhaps already provided by:
>
> http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA
>
> Harald Schilly could probably set things up so more people can wrangle the bugs
> that come in through that page.
I think that's rather orthogonal to the number of poorly filed tickets on trac.
>> Second, rather than have the default milestone be the next release,
>> have some default future milestone.
>
> There's no default milestone. See for yourself:
>
> http://trac.sagemath.org/sage_trac/newticket
>
> It being the next release is merely a social convention... That said,
> of course you mean "instead of whatever is done now..."
Yes, that's what I meant. There should be a good (non-blank) default,
as it currently does scream "change me."
>>Only tickets that are actively
>> being worked on get put on the current release. This would make it
>> much easier to see what's being worked on (or at least cared about)
>> and what to expect in the next release. Sufficiently important items
>> (blockers) would also get added here.
>
> Couldn't something like that be accomplished with a trac report
> showing the 50 "most active" tickets? Sort of like how
> http://ask.sagemath.org/questions/ by default shows the 50 most
> active questions, and http://mathoverflow.net/ shows the top 50 or so
> most active questions?
I think activity is not always an indication that something will go in
soon (though it would still make for an interesting report). Also,
release managers should feel free to bump tickets out of a given
release whenever they not comfortable with them (whether that be due
to lack of expertise or time or wanting to roll things to an end or
whatever. As a minor point, I also like the line-bar plot by component
releases have.
>> Thirdly, I think the list of components could be cleaned up.
>
> For the last year people kept asking to add new trac components (I
> know, because I had to add them). There used to only be a handful.
>
> Just out of curiosity, is trac still the best system to use for
> managing what we're managing?
Probably not, but I don't think our issues could be sovled by
switching systems alone (though it's probably worth doing). I do have
to say that mondrian (a.k.a. code review) is really nice to work with,
and I have to say that code reviews there are a much smoother process
than what we have with Sage. One key point is that it's far, far
easier to just fix and repost/refresh patch.
I agree, something needs to change, and it makes more sense to create
an agile offshoot. I suppose my sweet spot would be where Sage was 2-3
years ago: reviews were in place but usually quite quick, doctests
were good but 100% was not required, less worrying about the long tail
of operating systems. etc. (I'm probably suffering from golden-age
nostalgic blindness a bit here...) But that may not be what's needed,
especially to jumpstart things again. I just don't want to see psage
becoming a divergent fork of what Sage was in late 2010, or an
enormous amount of effort required to keep the two projects on a track
where they can continue to benefit from each other.
- Robert
Burcin Erocal
I'd say there is an unofficial list of people who care about bugs in
certain areas. The default assignments for the components on trac makes
some of these sort of official, but this system can definitely be
improved. (I certainly don't want to be the one to fix all the bugs in
the symbolics and calculus components.)
For a method anyone can follow to decide who might be the person to ask
about a problem reported to the issue tracker (after checking that the
problem is reproducible in the latest version), I suggest using
something similar to the method we suggest to find possible reviewers.
- Look at the backtrace, find out which line of what file raises the
error
- Look at the file in question and determine who wrote those lines
(with hg annotate) or who contributed to the file in general
- Notify two developers whose names come up
This process can be improved, to check if the error was raised by
unexpected input, if so, go up the stack trace and look at the previous
function.
Once the real point causing the problem is identified, it would take a
developer much less time to fix it.
Note that this approach, if we can set it up properly, will free more
developer time. Indirectly, this could help with more bug fixes, better
reviews on patches, etc. since the "veterans" can use their time more
efficiently.
Cheers,
Burcin
Burcin Erocal
"Dr. David Kirkby" <david....@onetel.net> wrote:
> To make matters easier to follow, lets look at Burcin's proposals.
>
> http://groups.google.com/group/sage-devel/msg/40d2af34d86586de?hl=en
>
> and consider them, here in an abbreviated and expanded form.
>
> 1) Burcin said: "Many of the bugs on trac are duplicates and could be
> closed."
>
> He is probably right. Some are undoubably wrongly categorised, but
> from a personal perspective I often don't have a clue what to file
> them under anyway. Perhaps for those of us without maths degrees, the
> categories could be more explicit. But even that is not a full
> solution.
This is exactly one of the points I wanted to address with the
proposal. Even if we make the components on trac clearer, new users
won't be able to choose one comfortably. It is far better to let
someone who knows (B-Team member) do this (hopefully soon) after the
bug is filed.
BTW, after practicing with a few bugs, this should be fairly
straightforward to do. Looking through the Sage library code to find
the lines with the problem or trying to track down the cause of a
problem is a great way to get familiar with the layout and structure of
Sage, the coding guidelines etc.
<snip>
> 2) Burcin said: "We might be able to overcome this with a
> "bug-wrangler" team, people who volunteer to ..."
>
> IMHO, If the categories could with a tick box, then this step could
> hopefully be removed for future bugs. The right people will
> automatically be notified. We need however to have a category "I need
> helping chosing the right categories". That would be especially
> useful for those of us with a non-maths background, but I think to
> others too, as parts of Sage are so specialised, I doubt I'm the only
> one who struggles to know what to categorise things under.
Note that since we changed trac to let users get accounts themselves,
we let anyone file bug reports.
There is usually quite a lot of work that needs to be done before a bug
can be fixed. We need
- full examples on how to reproduce it,
- check if it is there on the latest release,
- see if it occurs on all platforms,
- check if it was reported before,
- find out who would know how to fix it
If you make a few people who know the Sage library well do all this,
then they won't have much time to actually fix the bugs.
The items listed above don't require so much experience with Sage. They
can be done by new developer candidates. The Sage project needs to
train new developers, since the veterans are already overloaded and
some have been lost to burnout already. I suggest this as one way to
train new developers.
> I think the lack of too many "sign me up to do this" shows there's
> not likely to be the number of developers taking this on. They might
> be more attracted to do it if they realise that it only needs to be
> done once, and new bugs would automatically be assigned to the right
> person.
Considering the general lack of enthusiasm on the lists recently, I
would say the amount of response my suggestion got quite successful.
> Even if you understand what the bug is, the chances are you don't
> know who is the best person to look at the bug.
Given a reproducible bug, developers can easily tell who might be able
to fix a bug. However this takes some time, so many people might even
be reluctant to go through these steps if they don't feel like
actually fixing the problem. See my response to Jeroen Demeyer's message
for a longer answer to this.
> Several categories have nobody at all assigned to them. Since I'm an
> admin on trac I can see this. These include:
>
> * cygwin
> * debian-package
> * distribution
> * dsage
> * experimental package
> * factorization (this one *really* surprises me)
> * msvc
> * optional packages
> * packages
> * performance
> * PLEASE CHANGE
> * relocation
I suggest merging
- packages, optional packages, experimental packages
under the title "packages"
and
- "AIX or HP-UX ports", build, cygwin, debian-package, distribution,
FreeBSD, msvc, porting, relocation, solaris, spkg-check
under the title "distribution"
The mathematical components can probably be merged as well. For
example, I agree that "factorization" stands out quite a bit. :)
Thanks for bringing the discussion back on topic.
Cheers,
Burcin
Burcin Erocal
William Stein <wst...@gmail.com> wrote:
> On Wed, Oct 20, 2010 at 7:41 AM, kcrisman <kcri...@gmail.com> wrote:
> >
<snip>
> >> Not to be overly pessimistic, but one metric we do not collect,
> >> but Google do for us, is the number of posts each month to
> >> sage-devel. There has been a very dramatic falloff this year
> >> compared to all other years.
> >>
> >> http://groups.google.com/group/sage-devel/about?hl=en
> >> http://groups.google.com/group/sage-support/about?hl=en
> >> I think the number of posts to sage-support is more worrying than
> >> to sage-devel, but I believe the combination rather shows that we
> >> are unlikely to find a lot of developers taking on Burcin's
> >> proposals.
> >
> > Hmm, that is interesting. I don't know if it means anything (it
> > might), but it is interesting. Thanks for that.
>
> I take it to mean that Sage is now a mature project with roughly the
> right number of developers.
I strongly disagree with this. Although I see that you also support the
fact that we need more developers as a follow up to this comment.
I am quite disappointed by the fact that the sage-devel list has turned
out to be a place to discuss how to compile mathematical software on
various platforms, instead of how to do mathematics with the computer.
This is partly because there are now specialized lists such as
sage-algebra, sage-combinat-devel, sage-nt. Unfortunately, those lists
are not used much either.
I agree that the distribution part of Sage is very important, since it
gives a lot people easy access to many open source mathematics
packages. The developers and the maintainers of these packages should
have a platform to share experiences and learn from each other.
However, I don't think sage-devel is the right place for this. Perhaps
a sage-porting list would be more useful.
> That said, everybody should keep
> recruiting new people as aggressively as they can, since developers
> come and *go*, as they have children, have to finish a thesis, get
> involved in other projects, finish making the contributions to sage
> they find interesting, etc.
+1
Not only because people "come and go". Sage is getting larger everyday
and many of the current developers are already spending more time on it
than they should. (I should be writing my thesis ATM.)
Cheers,
Burcin
Burcin Erocal
William Stein <wst...@gmail.com> wrote:
> On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw
> <robe...@math.washington.edu> wrote:
> > On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen
> > <J.S.R....@mat.dtu.dk> wrote:
> >> I think that Burcin's suggestion is excellent. Development of Sage
> >> should definitely move towards more structure, documentation,
> >> testing and other software engineering practices, but as for any
> >> Open Source- project, these things should come naturally as the
> >> project grows and matures; as has already happened with Sage a
> >> lot, it seems (for a relative new-comer like me). To require too
> >> much too soon would kill the joy of working on the project and
> >> thus kill the project itself.
> >
> > +1 I have definitely seen that the level of bureaucracy has going
> > up, especially in the last year or two, has turned off a lot of
> > potential and even former developers.
>
> Another +1. The level of bureaucracy has gone up so much in the last
> year that it has very seriously turned off me.
+1 from me as well. Though I'd say the expectations from the developers
have gone up not just bureaucracy, with the requirements to do the jobs
that could be automated etc.
I see the bug wrangler, or the B-team, as a way of lowering the load on
developers, and perhaps a possibility to gain new ones.
<snip>
> > I'm not sure I have a solution, but one thing that keeps coming to
> > mind is that Sage is trying to span several audiences with different
> > goals and criteria, and perhaps the various audiences would be best
> > met by a stable vs. unstable model like Debian. Purple sage is an
> > extreem move in this direction (more like Debian experimental)--I
> > can certainly see the attraction and value, but I just hope it
> > doesn't become an incompatible fork.
>
> A difference from debian experimental is that PSAGE starts by removing
> over 20 standard packages from Sage. In fact, so far, that is
> essentially *all* that PSAGE is. Also, my intention is that most
> Python code in PSAGE go into a different Python module than the "sage"
> one.
We could also think about making Sage leaner, and easier to extend.
Then the main Sage team can maintain
- Sage-core with these 20 packages removed, which is as easy to
install as Sage
- Sage with the current mathematics functionality, and maybe more, as
an alternative to the M's
<snip>
> > I agree that a big part of the problem is that it's hard to get a
> > big picture of all the bugs being worked on. The idea of a weekly
> > "bug-wrangler" is an interesting one. I have a simpler proposal
> > (which may be insufficient, but would complement a bug-wrangler's
> > role and is much easier to implement).
> >
> > First, have the initial status of tickets be some pre-new stage.
> > (Something like "unclassified".) This woud make it so you don't have
> > to be an expert to classify a bug. Volunteers could go and look at
> > all unclassified tickets and file them appropriately (severity,
> > defect vs. enhancement, component, duplicate, etc.) Of course,
> > there could be a rotating bug-wrangler, but if it was easy enough
> > for a "veteran" to hop on and categorize a bunch of them in one
> > sitting this might not even be necessary.
>
> This is perhaps already provided by:
>
> http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA
>
> Harald Schilly could probably set things up so more people can
> wrangle the bugs that come in through that page.
I was thinking of formalizing this with the bug wrangler approach.
Harald cannot possibly deal with all these. The difference between this
and the new issues filed on trac is getting less as everyone can file
new issues on trac (even though the trac interface can be intimidating).
<snip>
> Just out of curiosity, is trac still the best system to use for
> managing what we're managing? You work at Google and they have their
> own free http://code.google.com/ thing, which provides similar
> capabilities to trac, but with integrated code review, the possibility
> to delete comments (w00t!), etc., native support for Mercurial (which
> trac barely supports, preferring SVN), easy forking, etc. I have so
> far little experience with code.google.com, but I'm sort of curious
> how good it is. I set it up for PSAGE here
> http://code.google.com/p/purplesage/ since I didn't want to have to
> manage a whole trac, hg repo, etc., yet again.
I have grown very fond of the tracker used by Python recently:
I like the fact that you can do everything via email. This feature
would provide an easy way to submit patches you're working on to the
issue trackers. We could just hook up to the email functions of
mercurial.
IIRC, Jason suggested at some point to take a look at
for patch reviews.
I am still reluctant to host the project on Google...
Cheers,
Burcin
Jason Grout
> I have grown very fond of the tracker used by Python recently:
>
> http://roundup-tracker.org/
>
> I like the fact that you can do everything via email. This feature
> would provide an easy way to submit patches you're working on to the
> issue trackers. We could just hook up to the email functions of
> mercurial.
8 years ago, I implemented a Roundup-based ticket tracker (after looking
at a lot of systems), and was impressed with the configurability.
I haven't used ReviewBoard, but it did look interesting.
And my 2 cents: I agree with others that something needs to be done to
lower the wall again for new contributors. I too have heard or seen new
developers be overwhelmed by the amount of time needed to do a simple
fix. I've also been slowed down a lot by the time it takes to review a
patch, so a big +1 to Robert's work on a build-bot that tests any
needs_review ticket automatically.
Thanks,
Jason
--
Jason Grout
Burcin Erocal
Martin Albrecht <martinr...@googlemail.com> wrote:
> > I was thinking of setting up trac to send a notice to a mailing list
> > for each new issue. Then people interested in this effort can follow
> > this list and help out. Is this possible? Can someone familiar with
> > the trac set up comment?
>
> > IMHO, distributing work day by day, or weekly is still putting too
> > much load on one person. It should be enough if someone contributes
> > to one issue per day.
>
> > Perhaps we should come up with a locking mechanism, to prevent two
> > different people from trying to sort the same issue at the same
> > time, but it feels like too much organization at the beginning.
>
> My guess would be that we won't have the issue with locking very
> often (i.e. too many people doing too much work) but with no one
> feeling responsible. I guess for me your suggestion would turn out
> something like this:
>
> 1) I sign up to that mailing list since I feel a responsibility of
> contributing to Sage in such a way
>
> 2) For the first few days or weeks I go through newly opened tickets
> as you suggested.
>
> 3) Eventually, probably in some phase where I have less disposable
> time, I give up on dealing with this e-mail since "somebody else will
> take care of it".
I know this scenario too well. We should try to avoid overloading
people or relying on the efforts of only a few people as much as
possible.
> Of course, the answer could just be to not do step 3, but I would
> assume that it would happen to many of us. Being responsible for a
> week a time is something more local or short-time which would make it
> easier for me to commit.
The week at a time approach you describe below is too much work for me.
I doubt if I could put in 2 hours of work for Sage everyday for a whole
week. I do however look at the new tickets on trac from time to time,
and wouldn't mind either classifying a few of the new ones properly, or
reading emails to see if a new developer has done it properly.
> To given an example of the workload here's the list of tickets
> created on the 15th. It seems 3-5 new tickets a day is the normal
> load:
>
<snip ticket descriptions>
> Thus, as a rule of thumb we could say whoever is responsible for a
> day should deal with five tickets old and new. This seems like about
> 1-2h of work which seems doable to me.
>
> Of course, if many people feel differently then we should choose a
> different path.
I suggest still setting up a mailing and assigning all new bugs to a
B-team user on trac with email address pointing to this list.
Following your suggestion, to make sure there is someone "in charge" for
a particular day, we can set up a wiki page to sign up for days (not
weeks). It would be great if we can have at least 2 people on call for
a day. Though it is not a disaster if a few new entries get missed,
since we can always process them later. We just need to make sure not
to build a huge backlog, and do as much preprocessing as possible before
assigning a bug to a developer.
For anyone who cannot commit to a regular schedule, a search on trac for
tickets assigned to the B-team will point what needs to be classified,
so they can help at any point without signing up if they wish to.
The B-team should be responsible for doing the following before passing
a bug on to a developer:
- make sure there is enough information to reproduce the problem
- check if it is already reported, if so close the current as a
duplicate
- find which area of the code the problem seems to occur
People can always ask for help on the mailing list if there is a
problem with this phase.
- assign to a developer only if they agree to work on the problem,
otherwise leave the issue in a "confirmed" state, assigned to
"tbd" (these terms can also be used to search for things to do...)
The B-team can also handle the "report a problem" link from the
notebook, the problems reported on ask.sagemath.org, or the
sage-support mailing list, as required.
Comments?
Any takers? I'd like it if someone takes the lead for the next few
months, since I really need to be working on finishing my thesis. I am
still willing to spend some time on bug wrangling these days, since I
try to do that already (like quite a few other people) so I can still
sign up for some days.
Cheers,
Burcin
Jason Grout
> The week at a time approach you describe below is too much work for me.
> I doubt if I could put in 2 hours of work for Sage everyday for a whole
> week. I do however look at the new tickets on trac from time to time,
> and wouldn't mind either classifying a few of the new ones properly, or
> reading emails to see if a new developer has done it properly.
Same here. I often look at bugs in categories I'm "fluent" in to give
some initial feedback. I can't commit an entire week to it, though. I
could take a day or two.
Thanks,
Jason
Jason Grout
> IIRC, Jason suggested at some point to take a look at
>
> http://www.reviewboard.org/
>
> for patch reviews.
Here is one more possibility, though it may be too formal for our needs:
Java Code Review: http://jcodereview.sourceforge.net/
Jason
kcrisman
thoughts vis-a-vis PSage. Regardless of whether he's spending more
time on PSage right now, I think that for many OSS projects it's
difficult to maintain momentum when the lead developer steps back a
fair amount.
Sage has done quite well during this time, but my guess is that if the
BDFL were to make some official pronouncement about cooling it (in
some specific way) on the bureaucracy, that would be better than a lot
of arguing about it. It would be terrible if Sage lost momentum just
at the point where it is achieving much more mainstream recognition.
If we can get to the point where the following two things are
available (neither of which I am even remotely capable of providing):
1) Double-click Windows app (we have this with Mac)
2) Slightly more robust large-scale server "in a box" we can just
point people to who know NOTHING about admin
then I'd feel much more confident about the long-term prognosis for
Sage, even if a lot of the research-oriented community had friendly
extensions. There would simply be enough additional users that a
viable contributor base would be ensured for quite some time.
Directly addressing the thread:
What impressed me the most about R at the useR! 2010 conference was
the automatic build testing for all the (many, many) optional
packages. I think most of us want to keep Sage working on a big
variety of platforms (I certainly do, for some of the meta-reasons OSS
is good), but the sheer time involved without this automation for
anything that uses non-Python code (esp. upgrading spkgs) is
overwhelming. But this project seems to be further away than 1) and
2) above, which are so close to fruition.
- kcrisman
William Stein
<robe...@math.washington.edu> wrote:
> Thus psage will be a superset of a subset of sage.
Yes.
> Do you envision a
> migration path of code from psage to sage?
Yes.
> (Perhaps not instigated or
> executed by the original authors of the code of course.)
Yes.
> Would it be
> easy to install the "missing pieces" into a psage setup, or,
> conversely, install the new parts of psage on top of Sage?
Yes, and yes.
> That being
> said, the sage-combinat model seems like it would be a huge amount of
> work to manage, but is nice for the end user. (Doesn't solve the
> messiness of ugly build problems with arcane spkgs...)
I want PSAGE to solve for me a similar problem that sage-combinat
faces. However, the solution I'm using is different. It is much more
flexible and powerful, and can have interesting benefits for Sage due
to it helping clarify some of the dependencies of Sage. E.g., the
first issue is about exactly how much Sage still depends on Maxima
http://code.google.com/p/purplesage/issues/detail?id=1
since Maxima is one of the standard spkg's not in PSage.
...
>> Again, I'm not necessarily claiming Sage itself needs to move that
>> quickly again. This is very difficult technically due to the larger
>> number of platforms supported, the larger test suite, codebase, etc.
>> But something does need to change, or some of the truly brilliant
>> computational mathematics researchers (like Mark Watkins, say) will be
>> unlikely to be drawn in again. For me, PSAGE will accomplish this
>> goal, while allowing me to continue to benefit from the incredibly
>> valuable high quality work that so many people are doing on making
>> Sage a solid, well tested, cross-platform system.
>
> I agree, something needs to change, and it makes more sense to create
> an agile offshoot. I suppose my sweet spot would be where Sage was 2-3
> years ago: reviews were in place but usually quite quick, doctests
> were good but 100% was not required, less worrying about the long tail
> of operating systems. etc. (I'm probably suffering from golden-age
> nostalgic blindness a bit here...)
Same here.
> But that may not be what's needed,
> especially to jumpstart things again. I just don't want to see psage
> becoming a divergent fork of what Sage was in late 2010, or an
> enormous amount of effort required to keep the two projects on a track
> where they can continue to benefit from each other.
Neither do I.
>
> - Robert
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
Dr. David Kirkby
I don't thinking lumping those lot together under the title "distribution" would
be sensible myself. It's would make finding things of interest even slower.
Especially given some of those have people that get notified about specific
areas, but don't want to get inundated with tons of messages.
Dave
Dr. David Kirkby
But it's a bit silly really, as everything is a package. I wonder if all 3
should be removed myself.
> and
>
> - "AIX or HP-UX ports", build, cygwin, debian-package, distribution,
> FreeBSD, msvc, porting, relocation, solaris, spkg-check
>
> under the title "distribution"
I don't thinking lumping those lot together under the title "distribution" would
be sensible myself. It's would make finding things of interest even slower.
Especially given some of those have people that get notified about specific
areas, but don't want to get inundated with tons of messages.
Robert Bradshaw
clear at http://purple.sagemath.org/dsage.html (though that page
really seems to be more about the differences rather than relationship
between the two projects).
Robert Bradshaw
I'd certainly be willing to pitch in, but probably wouldn't be able to
commit to specific days. If no one's opposed, I'll at least add a
"confirmed" state on trac.
- Robert
Robert Bradshaw
<david....@onetel.net> wrote:
> On 10/21/10 11:23 AM, Burcin Erocal wrote:
>>
>> On Wed, 20 Oct 2010 13:04:56 +0100
>> "Dr. David Kirkby"<david....@onetel.net> wrote:
>>
>>> Several categories have nobody at all assigned to them. Since I'm an
>>> admin on trac I can see this. These include:
>>>
>>> * cygwin
>>> * debian-package
>>> * distribution
>>> * dsage
>>> * experimental package
>>> * factorization (this one *really* surprises me)
>>> * msvc
>>> * optional packages
>>> * packages
>>> * performance
>>> * PLEASE CHANGE
>>> * relocation
>>
>> I suggest merging
>>
>> - packages, optional packages, experimental packages
>>
>> under the title "packages"
>
> should be removed myself.
But not all packages are on the same footing--the Sage library being
an excellent example of something that's much more than "just another
package." By "packaging" I would think of tickets involving the spkg
install system, spkg checks, etc. that require compiler and shell
scripting skills. In this sense, all packages are more similar than,
e.g. number theory vs. packaging.
>> and
>>
>> - "AIX or HP-UX ports", build, cygwin, debian-package, distribution,
>> FreeBSD, msvc, porting, relocation, solaris, spkg-check
>>
>> under the title "distribution"
>
> I don't thinking lumping those lot together under the title "distribution"
> would be sensible myself. It's would make finding things of interest even
> slower. Especially given some of those have people that get notified about
> specific areas, but don't want to get inundated with tons of messages.
Perhaps porting would be a better title--and I could see the
justification for splitting Windows from non-Windows, but finer
granularity than that would not be of interest to the vast majority of
people.
- Robert