#9766: Cliquer - Update Upstream contact
------------------------+---------------------------------------------------
Reporter: ncohen | Owner: tbd
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.5.3
Component: packages | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------+---------------------------------------------------
Comment(by drkirkby):
Replying to [comment:6 ncohen]:
> > Nathann,
> > did you manage to finish this? The amount you need to do to get a
positive review is trivial.
>
> I have not had a "stable" internet connection for several weeks now
Sorry to hear that. I often lose mine from home, and it really annoying.
Particularly if I have a chess game scheduled as part of a team. Failure
to play lets the whole team down, so I have on several occasions made a 90
mile round-trip to go to my fathers, use his internet, then come home.
There's not even a local internet cafe here.
> On the technical side David, we have known for a long time that we view
development very differently.
Yes.
> I try not to forget that you want Sage to be a "professionnal" software,
with all the necessary -- what I call -- administration (standard
procedures for modification of the code, correct documentation, supporting
many platforms, changelogs, etc...). Even though it very often seems "too
much" for my way of doing, I have two things to admit :
I think if Sage is ever going to be a viable alternative to the commercial
products, it needs to get more professional in its approach. As Tim Daily
points out in that recent thread on sage-devel, if things are not
documented properly, then whole sections of code may need to be swapped
out as they are unmaintainable. This is very close to the case with
SYMPOW.
> * You think Sage will be improved through all this, and your intent
is good
> * It requires a lot of work, which you often do yourself
>
> In the end, even though I have a different way to work, it sounds like
we are both trying to work on the same piece of (great) software, as
efficiently as we can. This is why I am asking this question to a fellow
developper :
>
> There are necessary things in all this administration, to ensure that
everything stays correct (doctests, spkg-checks, ...), or documented, or
logged. But don't you think somethings goes really wrong when it takes 2
weeks, 2 persons, and 30 minutes or 1 hour of cumulated worktime to add an
url to a file ?
Yes, I do. It is a waste of peoples time.
> How do you think we could simplify these things ? I am confident any
mean you could name would never harm Sage's reliability.
* Sage has a Developers Guide. It's not that large, and I feel that
anyone developing for Sage should look at the sections which are relevant
to their work. Minh in particular has put a lot of effort into improving
Sage's documentation. Let's hope hope his, and others efforts to improve
documentation are not wasted, because people can't be bothered to read
them. I think you would have to agree it's a waste of time creating
documentation if it's not read.
* Had the original author set up SPKG.txt properly, as documented in the
section on
[http://www.sagemath.org/doc/developer/producing_spkgs.html#creating-a
-new-spkg creating a new spkg], CJ Fearnley would not have needed to
request the information for Debian. So first and foremost, whoever wrote
the SPKG.txt file in the first place, failed to follow the documentation,
and so has caused
* CJ Fearnley to write you an email
* You to create a ticket
* Me to review it.
* The release manager to merge the package
* You to write to CJ Fearnley to advise him the package is now
corrected.
* Next, had the reviewer for the cliquer package done their job properly,
they would have spotted the authors omissions,
* Finally, had you have taken a bit more care, and updated your SPKG.txt
to actually reference the ticket, and not copy/past the previous entry, I
would probably have given it a positive review immediately, though
probably put a note like "it could be useful if you added the missing
sections", and leave it up to your judgment whether you did that. Most
developers will make minor changes like that. But your entry was
confusing, so it needed to be changed.
* Once your entry needed to be changed, it did not seem unreasonable that
you add the missing sections at the same time.
> I promise you will have this spkg updated with the modifications you
requested as soon as I have a -- real -- internet connection. I may even
be able to find a way to send it tomorrow ! :-)
>
> Nathann
I believe I have spoke to you about the ''cost of fixing bugs''.
Basically, the earlier a bug is caught, the less expensive it it to fix.
In the case of Sage, we are primarily talking about peoples time. Had the
documentation error been picked up early, a lot less of peoples time would
have been wasted.
That's why I've tried to get over to you the point that you should spend
you time stopping the bugs in the first place, as it's less time consuming
to do that, than it is to fix bugs when they are reported.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9766#comment:8>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
