cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: What should it mean to +1 a release
Date Fri, 25 Apr 2014 18:55:11 GMT
:+1:


On Fri, Apr 25, 2014 at 11:45 AM, Jesse <purplecabbage@gmail.com> wrote:

> +1 to this also.
>
> Starting a new thread on the subject of automating #3
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Apr 25, 2014 at 11:35 AM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > +1 to this!
> >
> > On Fri, Apr 25, 2014 at 11:29 AM, Ian Clelland <iclelland@chromium.org>
> > wrote:
> > > On Fri, Apr 25, 2014 at 1:55 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > >
> > >> Had some discussions about this at ApacheCon, and I think it would be
> > >> good to formalize this in a release-process doc within coho/docs.
> > >>
> > >> The best Apache docs for it is:
> > >> https://www.apache.org/dev/release-publishing.html
> > >>
> > >> When we (or at least, members of the PMC), vote on a release, we
> > >> (should) be saying that we are confident that:
> > >> 1 - Our sources are properly licenses (aka, RAT or coho
> > >> audit-license-headers)
> > >> 2 - We have only compatibly licensed dependencies (and appropriate
> > NOTICE
> > >> lines)
> > >> 3 - Code is made up of commits by individuals that have signed the
> > >> ICLA (or that are trivial commits)
> > >> 4 - Archives are properly signed & hashed
> > >> 5 - Contents of archives match sha1 of what's in the repo
> > >>
> > >>
> > >> Note that this list doesn't include anything about the *quality* of
> > >> the code. This subject was more grey, and is more up to each project
> > >> to figure out.
> > >> - Some projects go as far as reviewing every commit that has occurred
> > >> since the previous commit
> > >>
> > >
> > > I was thinking about this, in light of the recent plugins release, and
> I
> > > think that it makes sense for quality concerns to be aired in the
> > [DISCUSS]
> > > thread that should be happen before the [VOTE] thread. That is a better
> > > place for anyone to step up and say "I think there are quality problems
> > > with component X; let's not release that just yet".
> > >
> > > That saves the release manager a lot of time packaging up a release
> > that's
> > > going to be downvoted anyway, and then the [VOTE] thread can be more
> > > efficient.
> > >
> > > This isn't saying, of course, that people *can't* downvote a release
> for
> > > any reason whatsoever, including quality concerns, but I think it would
> > > make surprises like that much less likely.
> > >
> > > Ian
> >
>

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