PS: yes, a Confluence page to track these things would be really excellent.
On Mon, 6 Nov 2017 at 01:08, Geertjan Wielenga < [email protected]> wrote: > Makes sense. > > In all cases the reason for files being removed is simple: the files in > question did not belong to Oracle and therefore could not be donated by > Oracle to Apache. > > For example, Oracle does not own the Safari trademark and therefore cannot > donate the Safari trademarked logos and icons to Apache. > > The question in Apache is whether those files, e.g., the Safari logo, are > licensed in such a way that they can be stored in Apache Git and > distributed as part of an Apache project. > > Indeed none of these questions apply to the files targeted for the alpha > release, i.e., the NetBeans Platform. Plus note again that incubator > releases do not need to be perfect, so long as their limitations are > clearly documented. > > Gj > > On Mon, 6 Nov 2017 at 00:59, Lars Bruun-Hansen <[email protected]> > wrote: > >> I have been going through this list. >> >> There are various categories of what has been done to the donation branch: >> >> - Binary artifacts removed because they are the product of some other part >> of the source tree >> - DTDs and XSDs removed (quite a lot more than has been uncovered so far) >> - Icons replaced with standard (dummy) NetBeans icon, for example all >> icons >> for Chrome, Safari, IE, etc have been replaced by a dummy >> - ...etc >> >> There are also many changes that are quite ok and which won't hurt. But >> certainly not true for all of them. >> >> For all changes it is true that the commit message is extremely short, >> never more than one line, and never once explains *why* the change was >> required. An example: Why was it necessary to strip color profiles from >> icons? Anyway, we will have to guess. >> >> It is too much for one person to review. I suggest to split the list of >> changes similar to what we did for the module review. For each change it >> should be evaluated what to do about it. If an action needs to be taken >> (e.g. to reverse) then log an issue for it in JIRA under a special tag, >> e.g. "donation fixes". >> >> What do you say to this approach? If so I'll create a Confluence page to >> track review progress. Compared to module review it is a lot smaller in >> magnitude but still requires a structured approach. >> >> In my mind the Alpha-Preview release task can still continue and doesn't >> have to wait for this. As long as that release is labeled "alpha" and has >> lots of big fat disclaimers on it. >> >> >> On Sun, Nov 5, 2017 at 10:36 PM, Geertjan Wielenga < >> [email protected]> wrote: >> >> > Thanks for this investigation. >> > >> > Gj >> > >> > On Sun, 5 Nov 2017 at 22:32, Lars Bruun-Hansen <[email protected]> >> > wrote: >> > >> > > I think we need this. >> > > >> > > The following URL is - to the best of my Hg knowledge* - a list of all >> > > changes done specifically to the donation.zip. (1st donation) .. >> before >> > it >> > > was handed over to Apache NetBeans. >> > > >> > > >> > > >> > > http://hg.netbeans.org/releases/log?revcount=1500&; >> > rev=%28branch%28%27donation_review%27%29+and+ancestors% >> > 28tag%28%271st_donation%27%29%29%29+-+merge%28%29 >> > > >> > > >> > > In plain text, this is the following search: >> > > >> > > "(branch('donation_review') and ancestors(tag('1st_donation'))) - >> > merge()" >> > > >> > > >> > > Enjoy >> > > >> > > >> > > *) Hope someone with better Hg skills can verify. :-) >> > > >> > >> >
