On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher <dave2w...@comcast.net> wrote: > > > > > On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > > > > On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher <dave2w...@comcast.net> wrote: > >>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> > >>> wrote: > >>> > >>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <dave2w...@comcast.net> wrote: > >>>> > >>>> Hi - > >>>> > >>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz > >>>>> <bdelacre...@codeconsult.ch> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean > >>>>> <jus...@classsoftware.com> wrote: > >>>>>> ...I put up suggested text changes for an incubator disclaimer here > >>>>>> [1]... > >>>>> > >>>>> Basically just adding this, right? > >>>>> > >>>>>> Some of the project releases may not follow ASF policy or have > >>>>>> incomplete or unknown licensing conditions.... > >>>>> > >>>>> It works for me but I'd say "incubating project" to be clearer. > >>>> > >>>> How is this? > >>>> > >>>> “Some of the incubating project’s releases may not be fully compliant > >>>> with ASF policy. For example, releases may have incomplete or unreviewed > >>>> licensing conditions. Known issues will be described on the project’s > >>>> status page." > >>> > >>> I would suggest we have a policy where known issues are actually > >>> listed in the DISCLAIMER itself. Along the lines of: > >>> > >>> "Some of the incubating project’s releases may not be fully compliant > >>> with ASF policy. For example, releases may have incomplete or > >>> unreviewed licensing conditions. What follows is a list of known > >>> issues the project is currently aware of (note that this list, by > >>> definition, is likely to be incomplete):” > >> > >> -1. > >> > >> This only works for issues known before a release is cut. It does NOT WORK > >> if the issue is discovered during the release vote. Why? Because we are > >> trying to allow the release to go through without redoing it and this > >> would require reworking the release. > >> > >> I would rather do it outside of the release. Policing the actual > >> DISCLAIMER is not easily feasible and decreases the burden. > >> > >> If this is the decision then it leads to a choice that is worse than the > >> status quo. > > > > Nobody is suggesting the policing bit. What I'm suggesting is a > > central place for that information to be collated. Whether that > > becomes a showstopper for a release gets decided by the VOTE. But what > > I'm saying is that we shouldn't be in a position where we have to hunt > > for *known* and *acknowledged* issues all over the place (JIRA, > > mailing lists, wiki, website, etc.). Lets at least make sure we make > > our downstream consumer's life a bit easier. > > My suggestion is that we put these onto our neglected status pages. I’m also > willing to work on enhancing the status page and process to make this easy > for Podlings to do.
Sure, that's a reasonable place too, but the problem is -- it doesn't help our downstream consumers. What I'm trying to say is this, I'd like: 1. this information to be available in one centralized location (per project) 2. be easily discoverable by downstream consumers If we all agree that #1 is desired (and sounds like we are). Then #2 can simply contain a link to #1 -- that'd be fine. Makes sense? Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
