Hi Wez,
As you said, it's pretty straightforward to handle bugs this way, but
a pain to open a ticket for every little maintenance job. We solve
that problem by opening up a maintenance ticket per milestone (eg:
X.Y.Z release maintenance ticket) and use that as a catch all for
those misc commits.
When we're done with working on a ticket in trunk, we set its priority
to merge so that we know that it is ready to be considered for merging
down to the stable branch(es), and we close it only when that merging
is complete.
This could work, except of course we don't have any such thing as 'a
maintenance ticket' or a way to set priority to 'merge'. It's kind of the
opposite way around to the way the PHP bug system works... and it probably
would be a pain to have it as part of an open system (in the sense that
users can add to it). Perhaps adapt the bugs *interface* to deal with
maintenance tickets along the lines you suggest, but with a separate db and
ID system - so we get #M9999 rather than #9999, and 'merge', 'no-merge',
'close' as the options?
This process should be pretty easy to translate to php.net
development. I'm not saying that this is the one true way to do
development, but it works for us at OmniTI.
It's the difference between a controlled environment and open source....
but I can see it working if the 'per milestone' route is taken, that's a
good idea. Anyone with QA/bugs karma care to intervene at this point?
- Steph
--Wez.
On 5/28/07, Steph Fox <[EMAIL PROTECTED]> wrote:
Hi Wez,
>I think the key is in forcing every commit to reference a ticket; that
> way you can't "lose" a changeset by forgetting to put a bug number in
> there.
Going back on-list... It's a good idea in principle, but I can foresee
some
problems with it.
Many (most?) of the unnumbered fixes Ilia's been making have been
alterations to internal string or memory function calls. Generally those
are
either performance or security changes, replicated throughout the code
base
and starting with a single 'blast' aimed at upgrading everything,
followed
by lots of smaller catch-up fixes over the next several weeks. This kind
of
thing isn't really worthy of a bug report, unless you have an entirely
new
concept of what a bug might be and allow for change types like
'maintenance', 'security' or 'performance' via the bug database somehow.
The
nearest we've come to that recently is MOPB - everyone marked those fixes
as
such - and occasionally coverity.
If the bug db allows it it might make sense to put an initial function
change as a 'maintenance' report with some explanation and a number,
e.g.:
helly Sat Feb 24 18:20:46 2007 UTC
Modified files: (Branch: PHP_5_2)
/php-src/main snprintf.c snprintf.h
Log:
- Add [v]slprintf to overcome the returnvalues issue of snprintf
would get a fuller explanation on the report, and every subsequent
"snprintf() -> slprintf()" commit would reference that maintenance report
number. Fine, but what to do about "malloc() -> pemalloc()"? Would all
'maintenance' fixes require a test script? Wouldn't the need to check for
a
maintenance number put devs off making a simple one-line fix?
Branch-specific fixes are generally (but not always) marked as such at
present. People tend to mention it in the 5_2 branch but not in 4_4.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
