Justin Deoliveira wrote:
> As for inactive module maintainers, when was the last time we went
> through all the modules and pinged module maintainers. Perhaps it is
> time for that again. I can volunteer up some time to go through each pom
> and generate a list of the module maintainers.
>
I pin
Some of this should be handled by the developers guide policies. See
section on hacking, and the ability for a PMC member to moderate in the
absence of feedback from a module maintainer. This is the formal
procedure, you may also get by with a simple line of communication with
the module mainta
Interesting... but I think Paul is right when he states that this will
probably just hold people back who are active. And with our lack of
personpower I dont think we want to do this.
As a module maintainer I am ok with having commits going through without
my review if I cannot respond within thre
The problem with that solution is that our Developers Guides says
that a Module Maintainer has 3 days to respond to the patch before
another committer can apply the change. This solution would make
that impossible... Unless that is what people actually want. I
suppose we could vote on it.
I can provide a programmatic fix to this problem, if you like, and
that is to turn on directory restrictions in SVN, and only provide
write access in modules to the maintainers. That way a true patch-
queue would be enforced. However, it would potentially cause huge
bottlenecks where inact
During a talk I had with Justin we decided that a good policy for
collaboration on a module (assuming all module maintainer agrees to
this level of collaboration) is:
1. Create a JIRA (make sure to assign it to Module maintainer)
2. Create a patch and attach it to the JIRA
3.
a) Modu
Justin Deoliveira wrote:
>Sorry for the late reply, but this commit already went through I take it.
>I was hoping to get a chance to review it first. With Chris bringing up
>policy, I am having some issues with commit and ask questions later style
>we seem to have adopted.
>
>
Fair enough i
Sorry for the late reply, but this commit already went through I take it.
I was hoping to get a chance to review it first. With Chris bringing up
policy, I am having some issues with commit and ask questions later style
we seem to have adopted.
One thing I would like to ask is that before any more
Cool, just did a quick code review, and things look pretty good.
One big thing missing though is parallel commits to trunk. We've been
bad at this, and it wasn't something we talked about in switzerland -
how to make sure we don't miss all kinds of bugs when we upgrade stable.
We should ge
Howdy,
I've been doing a little bit of PostGIS QA this week, as a few wriggling
bugs still live on.
Changes include:
- exposing the ConnectionPool (this is mostly so tests may obtain a
connection and create tables)
- PostgisDBInfo object (encapsulated version info -- since several
methods were
10 matches
Mail list logo
