Yo,
So after a bunch of ticket triage, I've got a system I feel reasonably
confident can work out to help us keep our milestones slightly more in
check from here foreward. Here are my suggestions; we can see what
everyone thinks.
1. New bugs in the code go into the current milestone, up until the
time when a release is starting to be prepared. (For 2.8, this is
'now'.) At that point, bug reports go into the *next* release, and
the 'current' release is for new regressions only, generally.
2. New feature requests go to the "Future" milestone, unless a
submitter is actively working on them or a patch is attached and
ready for discussion/review, at which point it moves to the 'curent'
milestone, with the same caveat re: releases.
3. Anyone who writes a sufficient patch should make sure that ticket
is:
* in the current milestone
* Marked for review
If code is insufficient/needs more work, it sould be marked as
'needs more work'. (Tickets which do not have patches should never
be marked 'needs more work'.)
This is the case until the release manager declaes a cutoff for new
patches. For the 2.8 release, I blieve there will be a hard deadline
of April 1st for "No new patches".
Side effects of this:
* Bugs should be in next release
* Features should be in 'future' unless they're actively in development
* Only things that have not yet been put into a milestone by someone
who feels competent to decide should be in the 'none' milestone.
Currently, 'none' is empty. I think that we should keep this as our
incoming triage queue for users/developers who don't know the system, so
this should be the default. Then we can triage from there.
I think that this solves all the needs I'm aware of us currently having.
Obviously, these are guidelines. Currently, a number of things in the
2.8 milestone are there despite not having patches because I believe
developers plan to work on them before 2.8, but there are 104 tickets,
and I'm positive we won't get a chance to fix/review that many.
One thing about the previous state of our tickets is that there were 110
tickets in the 'none' milestone, with more than a dozen already having
patches. Anything which looked even vaguely committable went into 2.8's
'review' queue; I xpect many of these will get a quick review and boot
to 2.9 with "Needs More Work", since many of them are likely old.
One thing I'd like to encourage is for other developers to participate
in the review process. Though thus far we've priarily encouraged trunk
committers to review, I think that a second pair of eyes on a ticket can
make the review process for a trunk committer *much* easier. Things to
do when reviewing:
* Check out a clean trunk copy of OpenLayers
* Apply the patch in question
* Run the tests in any browsers you have handy. (If there are no tests
for the patch, consider writing some! If you can't, explain why you
think that it's not easy to write tests. A manual test can often help
even if you can't do test.anotherway test writing very well.)
* Open the example, test the functionality. If this is a new feature,
it should have an example; if it's a bugfix, you should be able to
confirm the new behavior with the old example.
* If it's a new feature, attempt to -- using the documentation (and not
by reading the code) -- modify the example sufficiently to make it
do something different, and ask yourself if there is more that needs
to be demonstrated or written to help show off the feature. For
example, you might want to link to some documentation on a remot
eservice that describes how to set up the server sie component of a
feature or some such.
* Comment to the ticket, explaining what you did, how it turned out,
and whether you think the code in question is ready for trunk, or if
it needs more work in some way.
There are *many many* experienced JavaScript developers in the
OpenLayers community, and currently 50 tickets awaiting review in the
2.8 release. If we had a dozen people each grab four, or two dozen
people each grab two, we could really make a difference in the current
mountain of todos before 2.8.
If you feel lost in reviewing any existing patches, please feel free to
comment to the list in this respect. I'd be glad to help out in
directing how to do things like write tests, apply patches, etc.
One last thing: if you review, don't leave your comments as the
'openlayers' user. Especially now that you can create an account without
sending an email, please sign your comments so we can at least have a
unique identifier for who is talking.
I'm looking forward to feedback on my proposed triage system, or
other comments on this. Looking forward to a great release!
Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
