[modules-dev] Open Bugs/RFEs in java/module
Stephen J. McConnell
mcconnell at dpml.net
Mon Jan 21 07:23:40 PST 2008
On Fri, 2008-01-18 at 14:12 -0800, Andreas Sterbenz wrote:
> Stephen J. McConnell wrote:
> >
> > Can you provide a summary of what this periodic report actually is (as
> > opposed to the other periodic report that appears with the same subject
> > that lists some 39 outstanding bugs)?
>
> The empty report was just due to some changes in an internal system that
> this report generation script did not handle gracefully. I have fixed that
> and things should be back to normal going forward.
Latest reports seem to demonstrate that the problem has been solved (we
are back to the 39). In the meantime - can you provide some details
about the codebase in question here? Are the periodic reports
reflecting actual work-in-progress or are we simply looking at an
automated process that is linked to the last public release of the
codebase?
Something that would be much more interesting would be a periodic progress report with details of:
a) EG activity summary (294 and 277)
- new or updated info
- summary of external comments and info
(e.g. out in blogland, or the latest youtube
presentation)
b) legal and administrative processes
- political issues/obstacles
- licensing issues/obstacles (e.g. publication
of strawman documentation, revision to spec
licensing, ...)
c) codebase development
- technical issues/obstacles
- infrastructure progress (i.e. there are lots
of outstanding promises re. integration into
the OpenJDK process - mercurial migration,
synchronisation with version 7 ...
d) roadmap
- admin stuff (e.g. changes on the EG)
- outlook for the next quarter (priorities,
targets, expectations)
All of the above would be consistent with section 2.1.1 of JCP 2.6 ([1]):
"While Spec Leads are free to operate Expert Groups in
whatever style they feel is most appropriate, they are
encouraged to choose a style that provides maximal
transparency to the Expert Group, community, the EC
members and the public. The PMO provides Spec Leads with
tools and techniques for making the actions of their
Expert Groups transparent, and the EC members expect Spec
Leads to carefully choose which tools are best for their
Expert Groups and commit to using them. Transparency is
valuable to everyone in the community, especially the
Expert Group, because it offers broader feedback to the
group and helps build broader support for the final spec."
What do you think?
Cheers, Steve.
>
> Thanks for pinging,
> Andreas.
>
--
Stephen J. McConnell
mailto:mcconnell at dpml.net
http://www.dpml.net
More information about the modules-dev
mailing list