Gunnar, I like your proposal it is something we could move forward with. I would have never thought of this - awesome idea. -Tony
> On Feb 11, 2017, at 4:01 PM, Gunnar Tapper <[email protected]> wrote: > > Hi Tony, > > I did look up all committers. :) > > My point is that one of the committers have to be release manager since a > contributor does not have the right privileges to go through all the steps > needed. > > In my experience, creating a release for any form of product is always a > matter of will with a team that have all signed up to the deliverables and > dates. This is hard enough in standard product development where a project > manager drives things forward. It's even harder in open source where there's > no real project plan or product road map. > > I've been thinking about how to deal with driving to a project plan in a > meritocracy system such as Apache. Here's my proposal: > > 1. Create a release page on the wiki. > 2. Populate it with a proposed schedule, content (with Jiras), etc. > 3.Give the standard 72 hours for people to review the page. > 4. Vote on the plan. +1 says you're in agreement, -1 says that you're not in > agreement with the plan so you need to provide a reason for the -1. > > I don't think the plan defines a hard date but rather aims for; for example, > "first half of March 2017" or something like that. > > Would this work? > > As for the time for the release, my estimate is 2-3 weeks once all the > content is in place. I'm sure there will be a few stumbles on the way plus > there are built-in delays due to the 72-hour voting window for each release > candidate. > > I hope this helps, > > Gunnar > > > > On Sat, Feb 11, 2017 at 2:09 AM, Tony Faustini <[email protected] > <mailto:[email protected]>> wrote: > Hi Gunnar, I think Barbara Gomes is working on #2 from your list below. So we > should have all three points covered. > -Tony > >> On Feb 10, 2017, at 10:43 PM, Gunnar Tapper <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Rutvij, >> >> Nice to "meet" you. >> >> I want to be clear that one of the *committers* have to create the release. >> The steps outlined in the Contributor Guide should get whomever takes on the >> task through what's needed but let's expect a few misfires. >> >> From what I've seen, it takes time with all the prep work so there's no real >> need to wait. For example, I'm hoping that one of the mentors can help get >> the PGP signed once it's been created. >> >> Do y'all have a target date in mind for a first release? I find that things >> get done when we all have a mental milestone in place. :) >> >> Thanks, >> >> Gunnar >> >> >> >> On Thu, Feb 9, 2017 at 1:14 PM, Rutvij Clerk <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Gunnar, >> >> I would be happy to work with you on preparing the release. In general, I >> agree with the scope of proposal for the v0.1 release. >> >> I would be happy to volunteer for #1. >> >> Thanks, >> >> Rutvij >> >> On Feb 09, 2017, at 09:46 AM, Gunnar Tapper <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Hi, >>> >>> I've been thinking about the 0.1 release. As stated before, the first step >>> of any Apache incubation project is to learn how to operate in the Apache >>> world. >>> >>> From a release purpose, I propose the following focus areas: >>> >>> 1. Ensure that the source tree is a source tree. From what I understand >>> (Justin can verify), the source tree should not contain; for example, jar >>> files but the source and means to build the "binaries" and package them up. >>> 2. Build instructions. People outside the project needs to be able to build >>> the code. >>> 3. Release artifacts. Package up the project into a tar file ensuring that >>> all the release requirements are met. >>> >>> That's it for 0.1. I recommend that other functions (install, test >>> libraries, etc.) can wait to later releases. >>> >>> Would this work? If so, who can take care of #1 and #2 so that we can move >>> to #3? >>> >>> -- >>> Thanks, >>> >>> Gunnar >>> If you think you can you can, if you think you can't you're right. >> >> >> >> -- >> Thanks, >> >> Gunnar >> If you think you can you can, if you think you can't you're right. > > > > > -- > Thanks, > > Gunnar > If you think you can you can, if you think you can't you're right.
