incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Making it easy for IPMC members to vote in favor of AOO 3.4
Date Sun, 01 Apr 2012 01:15:22 GMT
On Sat, Mar 31, 2012 at 8:48 PM, Dave Fisher <dave2wave@comcast.net> wrote:

>
> On Mar 31, 2012, at 3:29 PM, Rob Weir wrote:
>
> > On Sat, Mar 31, 2012 at 12:21 PM, Dave Fisher <dave2wave@comcast.net>
> wrote:
> >
> >>
> >> On Mar 31, 2012, at 8:37 AM, Rob Weir wrote:
> >>
> >>> On Sat, Mar 31, 2012 at 11:27 AM, Juergen Schmidt <
> >>> jogischmidt@googlemail.com> wrote:
> >>>
> >>>> On Saturday, 31. March 2012 at 17:14, Rob Weir wrote:
> >>>>> Try to imagine yourself in the IPMC, being asked to vote for the
> >> release
> >>>> of
> >>>>> AOO 3.4. You want to make sure the release follows Apache policies
> and
> >>>>> guidelines. You want to protect the ASF. You want to ensure that
> users,
> >>>>> including developers using our source code packages, get the greatest
> >>>>> benefit from the release. But you are faced with a 10 million line
> code
> >>>>> project, larger and more complex than anything you've faced before
at
> >>>>> Apache.
> >>>>>
> >>>>> What do you do? Where do you start?
> >>>>>
> >>>>> Honestly, I have absolutely no idea. It is daunting task. But I
think
> >> it
> >>>>> is in our best interest as a PPMC to make our AOO 3.4 Release
> Candidate
> >>>>> easy to review for the IPMC. This means understanding the common
> >>>> questions
> >>>>> and concerns they might have and preparing answers to these in
> advance.
> >>>>>
> >>>>> I've drafted an outline, and filled in some of the blanks, for a
> >> "Summary
> >>>>> of Apache OpenOffice 3.4 IP Review" document on the wiki. I think
> this
> >>>> will
> >>>>> help raise the IPMC comfort level by documenting in one place the
due
> >>>>> diligence we performed and the final results. It also highlights
the
> >>>>> unusual things that came up in this project, such as the "mere
> >>>> aggregation"
> >>>>> inclusion of dictionaries in the binary packages.
> >>>>>
> >>>>> Here it is:
> >>>>>
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Summary+of+Apache+OpenOffice+3.4+IP+Review+Activities
> >>>>>
> >>>>> Any help in filling in the blanks would be much appreciated, by
me
> (of
> >>>>> course), but hopefully also by the IPMC. If we should cover other
> >> topics,
> >>>>> add those as well.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> You have probably missed this
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+FAQ
> >>>>
> >>>> We have started a similar page and I would suggest that we consolidate
> >>>> these 2 pages immediately to avoid duplicated work and confusion.
> >>>>
> >>>>
> >>> I think they are subtly different. Your page is a summary of the
> release
> >>> package, what is included, what different directories do, etc.  It is
> >> good
> >>> for someone who has download the package, unzipped it, and is looking
> at
> >>> the files.
> >>
> >> I think that Marvin and Juergen have had productive conversations on
> >> general@i.a.o
> >>
> >>
> > Yes, that is part of what informed the choice of material to present.
>  But
> > it is worth looking beyond that.  The old saying is "every new class of
> > testers finds a new class of bugs".  The same could be said of reviewers.
> > Marvin found one class of issues. Other IPMC members will have their own
> > particular interests and areas of concern.
>
> Wearing my IPMC hat, you've heard what my interests are.
>
>
And that is important to note, that some of these are PMC interests, not
user interests, and not even downstream consumer interests.  Downstream
consumers need to be able to build, understand the license and notice
requirements that come with the use of our code.  They do not need to
review the SGA or RAT scans. Those are purely PMC concerns.  So I really
don't see those going into a README file.  But I do think it is important
for us to consolidate that info somepace.


Make the following readily available with a predictable impact on my time
> and a vote for a release will be eased..
>
>
This all makes sense to me except the README part.   What would a
downstream consumer do with a RAT scan or a discussion of the SGA?

-Rob



> >
> >
> >> Here is what I would want to see.
> >>
> >> (1) BUILD instructions.  An accurate and complete description of the
> build
> >> of the binaries from source including how much time it takes on various
> >> platforms. This would help an IPMC plan how much time they will need to
> >> check the release. This is about the mechanics. Also, how to run the RAT
> >> report.
> >>
> >> (2) README. This can be the description of the release, dependencies,
> SGA,
> >> RAT excludes and why, etc.
> >>
> >> (3) NOTICE and LICENSE will need to be at the head of the tree in the
> >> standard location. Additions for the Binary packages should end up in
> the
> >> appropriate place in those packages after the build. I expect that these
> >> may differ slightly depending on the target platform?
> >>
> >>>
> >>> The page I started is more about the process we followed, what we did,
> >> what
> >>> we removed, the decisions we made, and why. So it is more about the
> logic
> >>> of what we did.  Your page is more about the end results.
> >>>
> >>> But it probably makes sense to combine these somehow, I agree.
> >>
> >> Yes and no. I think that Rob is leaning in on the README and the other
> >> Wiki page is about To Dos. For the release, I think that there are
> >> different aspects of the project's contents that need to be explained in
> >> the each of four contexts.
> >>
> >>
> > For now I've cross-linked the two pages.
>
> Sure, one step at a time.
>
> Lots of good progress this month.
>
> Regards,
> Dave
>
> >
> > -Rob
> >
> >
> >> (1) BUILD - how does one assemble the source into a usable binary?
> >> (2) README - what are the project's components?
> >> (3) LICENSE - what are the legal obligations?
> >> (4) NOTICE - what are the copyrights?
>
> >>
> >> Regards,
> >> Dave
> >>
> >>
> >>>
> >>> -Rob
> >>>
> >>>
> >>>>
> >>>> Juergen
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> -Rob
> >>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message