Re: attach ticket to package?



Alan G Isaac wrote:

Let me take the 2nd point first. As a user, I have found it
hard to submit patches. And I am pretty persistent.
I therefore consider the barriers high.

Sorry to hear this. Of course, this is very much package-dependant
(your point, of course).
With lower
barriers, there would be more patches.
This would be a good thing.

Agreed!

As for your first point, I feel it is misdirected.

Sorry if I was misleading here. I was trying to put together
observations not only on the point you raised but also relevant to some
other recent suggestions about CTAN.

Ignoring the resource cost for a moment, it is easy to
imagine how this would work. A package would essentially
be like a very small Google code project: project managers
(maintainers) and authorized contributors would be able
to commit code using SVN. Anyone would be able to open
issues and attach patches, which could automatically
generate email to the maintainers and contributors,
which could then be ignored or acted upon. Perhaps most
importantly, this would easily allow for multiple
contributors (approved and added by maintainers, without any
CTAN intervention), and for maintainers to easily manage and
document "passing of the wand" to new maintainers.
It is hard to imagine that such an arrangement would not be
more likely to generate and retain useful package feedback,
regardless of whether the package was a "one off".

I see the point, but I think the devil is in the detail, as always. The
CTAN people have done a good job on trying to catalogue existing stuff,
but I suspect even if one could set something up as you outline a lot of
existing packages would remain "outside" the system. There would also
be some issues with large projects which already have other homes (for
example beamer and PGF/tikz come to mind). At best, such a scheme would
only slowly accumulate material.

I suspect that many people would be happy with a scheme as you outline
*if* someone is willing to set it up. This is obviously not a trivial
task: as well as an SVN (or whatever) repository, you need a pretty good
bug database, project permissions and a web interface (plus goodness
knowns what else). Then you need mirrors ... This is all do-able, of
course, but won't happen unless someone with the desire and skills to
make it happen volunteers. The problem is then of course that people
skilled with (La)TeX are already busy and don't necessarily have the
knowledge to build a *really robust* system as outlined.

Please don't take this as a negative view on your suggestion: it is not.
I'd be very happy to see a public SVN and bug system to support the
package I maintain. I just don't see the CTAN people being bombarded
with volunteers to set it up.
--
Joseph Wright
.



Relevant Pages

  • Re: This is [Re:] How to improve the quality of the kernel[?].
    ... The goal is to get all patches for a maintained subsystem submitted to ... The fact is, some maintainers are excellent. ... Let's say that we aim for 0.1 bugs ... Blarney, where mistakes don't happen, developers are perfect, hardware is ...
    (Linux-Kernel)
  • Re: Mantis package bombs
    ... distro and a little other 400 maintainers. ... I do understand your hesitation of the package seems so full of bugs ... a bugzilla may be the most ... I've had one bug oustanding since ...
    (Fedora)
  • Re: sunmanagers Digest, Vol 34, Issue 14
    ... Christopher sent me a link to ftp.cs.tu-berlin.de that has all patches sun ... Subject: SUMMARY: Setting up mail on a Solaris Server ... however I seem to be having issues finding a binary package. ... Problems while installing 108528-29 for Sol8 machine ...
    (SunManagers)
  • Re: [patch] Add the device IDs for AMD/ATI SB700
    ... Since Jeff covered both status of your patches and administrative issues ... It makes sense to put addition of _all_ new PCI IDs into the first patch ... and without maintainers worrying about your patches not applying cleanly. ... When you don't see a patch in the upstream git tree ...
    (Linux-Kernel)
  • Re: Solaris 8 - Kernel Patches Not Updating 64-bit Files
    ... tried installing the latest recommended patches as 'uname -a' ... Original package not installed. ...
    (comp.unix.solaris)