[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: uncommitted changesets
From: |
David Bateman |
Subject: |
Re: uncommitted changesets |
Date: |
Fri, 28 Nov 2008 10:23:38 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
Ben Abbott wrote:
I reviewed the changesets I've submitted and noticed that three are
still outstanding.
I don't think anyone wants to see patches go unlooked at in this manner.
It is really these contributions and how they are dealt with that is at
the heart of an open-source (free-software) project.
I think the issue here is that John has always been responsible for the
auditing of all patches before they are committed to the Octave
repository and he is look for a new job at the moment and so is unlikely
to be able to reply rapidly. He recently made the master repository on
Savannah open to a few developers so that they could commit without his
intervention, but we're all still in the mindset that John will be the
one to audit patches before they are committed.
There are a couple of ways forward for that point and we as the
community of Octave developers have to decide what to do. These might be
1) John finds a job that allows him to continue his work as the Octave
project manager, and things continue as usual. This seems to me to be
unlikely and so we can't count on it
2) Someone else steps forward and accepts the role of the audit of all
patches sent to the list. This also seems unlikely to me, and perhaps
not even a desirable thing to want to happen
3) We accept that a group of people will be responsible for the auditing
of patches before they are committed. In this case I think we really
need a good bug tracker, otherwise we will loose patches.. Yes I know
debbugs exists for Octave, but no one is using it, as its easier to send
to the mailing list and let John deal with the bug/patch tracking in his
head. This case needs a person to step forward and accept the role of
the bug/patch tracker and maintenance of this system
4) We might reduce the bar where a developer is accepted as some one
with commit access to the repository. The risk here is that faulty,
unaudited code will be committed to the repository. However, I'm not
sure this is a major issue, as with a large number of people building
from the repository regularly these issues will be found rapidly and
repaired..
My feeling is that a combination of 3) and 4) is what should be done, so
who volonteers for the job of bug/patch tracker manager :-)
As for the patches you identified
(1) [changeset] - x/y/zticklabel as a numeric vector
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-November/009375.html
Seems ok.. Applied.
(2) [changeset] Missing ScreenSize & ScreenPixelsPerInch properties
http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-November/009451.html
Seems ok.. Applied..
(3) [changeset] - have the gnuplot backend respect properties
http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-November/009469.html
This one is harder, as it a much larger patch and includes lots of
changes that are essentially whitespace changes. I applied and check
quickly your patch and it appears to work. So I applied it on the
principal that its a requested feature and if there are issues then
others will find them if I don't :-)
Cheers
David
--
David Bateman address@hidden
35 rue Gambetta +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)