Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of shaposhnik@gmail.com designates
 209.85.210.178 as permitted sender)
MIME-Version: 1.0
Sender: shaposhnik@gmail.com
In-Reply-To: <B1D5F01C-8EDC-4B07-A82B-77DE78BEF6A1@luminis.nl>
References: 
 <CA+ULb+sF7CpNQ_tmyWb0J6dHrSeA889Lb90xi-7=OAB27xqykg@mail.gmail.com>
	<CAPhv5g_GaOSz5vCqZvhek1=f_a8TWvVonjx0RXptrdnbTT_BpA@mail.gmail.com>
	<CA+T-u8cs3Sd5SEz3=Cwhu12ixWFwVFV9Ot3y+QXnoA2CjCUp5A@mail.gmail.com>
	<50EEC308.90501@dkfz-heidelberg.de>
	<B1D5F01C-8EDC-4B07-A82B-77DE78BEF6A1@luminis.nl>
Date: Sun, 13 Jan 2013 20:25:03 -0800
Message-ID: 
 <CA+ULb+u1g1Uf08fb67WaqZoq5nK8GG7wf3E3Xny=n99MWiJmng@mail.gmail.com>
Subject: Re: Celix release management/planning
From: Roman Shaposhnik <rvs@apache.org>
To: celix-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 11, 2013 at 11:19 AM, Marcel Offermans
<marcel.offermans@luminis.nl> wrote:
> I agree with Roman that it's good to have some kind of plan or roadmap, feature or date driven.
> Personally, I would like to see regular releases, even if they contain only minor updates.
> If big feature implementations would block releases, we could consider developing them on feature branches.

With my mentor's hat on I'd say that 2 things are pretty important to
the project: understanding what the project plans (even if long terms)
are for the next release and being able to easily track those goals.

Personally, I expect every honest release to be a combination of the:
   #1 general feel of the developer community that this particular set
   of source code is 'good'
   #2 a user community vouching for the fact that by and large it
   satisfies their use cases
   #3 developer/PMC community vouching for the fact that to the best
   of their knowledge the bits that comprise the release are safe to
   use from legal standpoint
   #4 a signal to the downstream projects that they may latch onto the
   new set of bits and expect them to provide a stable based for them

Now, releases are NOT a given in the open source projects. In fact,
a massively successful OS project I happen to be a part of (FFmpeg)
used to make a point out of NOT having formal releases. The rationale
there was that even thought we all were extremely comfortable at
claiming #1/#3 pretty much for any arbitrary point of our trunk
(we practiced a 'golden trunk' development model) we had no resources
nor interest when it came to investing in #2 and #4.

That flexibility, of course, was a direct consequence of not being part of
any umbrella OS initiative. If you're just on GH or SF -- you can have any
governance model.

I think it would be fair to say that being an ASF project comes with an
assumption that you will find time and resources to invest into all 4
of the above things. To some extent it is a bit of a forcing function
(especially #3) and it needs to be budgeted in when a project decides
to go with ASF.

Hence, as a mentor, I'd expect Celix to figure out when it is time for
it to have such a next milestone. It doesn't have to be full of exciting
new features, it just has to provide some level of incremental
progress and also deliver on #1-#4.

Let me know if you guys need any help with driving the release. Also,
I think at some point I might inquire about somebody potentially
volunteering as an RM.

Thanks,
Roman.