nathans wrote:
> [...]
> - release schedule
> - once-a-month useful? sustainable?
> o [nathans] seems to be working well, good balance between the
> frequency of release, amount of code change, and time spent
> doing releases & QA.
> [...]
> o nathans mentions next release will slip half a week to give a
> bit more time for his own dev work, more reviews/merges, more QA
> [...]
> - code reviews
> o nathans seeking more people to be doing code reviews, this is a
> big time sink and would like to see this task (which is at times
> very time consuming & not-fun-at-all) shared around more.
I believe we noted that these are interconnected issues. With Nathan
being the sole dev-branch gatekeeper, he needs to keep reviewing code,
even if someone else has also reviewed it. Spending a week per month
on release duties reduces the time available for reviewing, merging
others' stuff, and developing his own stuff.
> == Archive logging topics
> [...]
> - would "it" require new context type?
> o yes, to solve both the live/archive transition and multiple log
> aspects well [nathans]
> o general concerns expressed about overloading / shoe-horning
> functionality into existing context types when we clearly will
> need a new context type eventually [nathans]
Consensus was that we currently foresee no actual specific semantic
shoe-horning problem between the single- and virtually-concatenated
archives. (That should not be surprising, since virtual concatenation
can be implemented "as if" by pmlogextract-merging all the inputs
first, then using single-archive mode on the result.)
> o fche suggests continual addition of code until nathans complains
> during code review that its going too far is a Just Fine option.
A more scholarly retelling would be that the consensus was that we
should go ahead with such a prototype, while we and Nathan will keep
an eye out for unforseen semantic "shoe-horning".
> == Data integrity
>
> - whither the fche/fsync patches?
> o revisited review comments - nathans wants a well-thought-out API
> that tackles the meatier part of the problem (interaction between
> sync and rename); not content with a static inline in impl.h nor
> anything that unconditionally adds fsync's to client code paths
o fche pointed out that it should not be necessary to solve the
entire suite of problems in order to make progress on some of them
> o perhaps move attention from library to tools that need to be very
> careful, e.g. pmlogger_daily before culling inputs [kenj]
> o pmlogrewrite -i seems particularly exposed [kenj to investigate]
o fche to rework the fsync patches on a tool-oriented way, adding
the operation to pmlogger, and input-destructive processing tools
like pmlogrewrite -i and a (future) pmlogextract merge-and-delete
mode.
> == Supported platforms
> [...]
> - which unixes/distros are of interest? release binaries for them?
> o reviewed each of the binary platforms from oss.sgi.com Downloads.
namely: solaris (fork), linux (rh-flavoured + debian-unstable), mac osx
> - how do we share build/testing load?
> - how to gather evidence about compatibility assumptions
> - how to entice distro reps into presence in pcp community?
- noted that some other linux distros have pulled in pcp occasionally
- noted that we don't know what sgi is doing with our pcp binaries or
sources
- FChE
|