incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@gmail.com>
Subject Re: Proposal - Separate 2.x Git Branch
Date Thu, 29 Mar 2012 03:12:36 GMT
On Wed, Mar 28, 2012 at 20:34, Brian LeRoux <b@brian.io> wrote:

> Moreso july is somewhat arbitrarily around the OSCON which is when we
> all happen to be in Portland. Its a good excuse for a summertime beer
> with friends. =)
>

Oh, come on.  We don't really need MORE excuses for drinking beer, do we?
:-)


> Really, I like to think what we're doing is 'rolling releases' with
> one overarching goal and bunch of mini goals to get there.

...
> Rather than releasing too early, or too late, just release on a
> regular schedule. Thats the basic premise.
>

You're preaching to the choir on 'rolling releases'.  Been doing it for
years, successfully - usually 6 weeks working out better than 4.
 Especially if the devs are also doing some amount of support for the
previous releases (and we always are).

I like that the 1.x work is on this kind of schedule.  And I'd like to do
this with 2.x as well.

The problem is - I don't understand the scope of the 2.x work.  Maybe I'm
missing something.  Is there more detail than this?

    http://wiki.apache.org/cordova/RoadmapProjects

Show me the man pages of the cli tooling, for instance, so I can get a
sense of what the effort/complexity for it is going to be.

If I don't know the scope of the work, I can't really estimate how many
'rolling releases' we're going to have, and so can't estimate the final
release date.

I've also done date-based releases, plenty of times.  "Thou shall ship on
xx/yy/zzzz".  No problem, as long as the customer understands that there's
a risk that function may need to be cut.  Cutting quality is never an
option, and extending the date is supposedly not an option, so when push
comes to shove, function gets dropped.  Customer gets to decide.  Sometimes
they decide (implicitly) to cut quality, by saying the date stays AND no
function gets dropped SO now you're in super crunch mode.

But I don't want to drop function or quality for 2.x.  I don't want to have
have the 2.x release where we say - "but wait till you see what we give you
in 2.(x+1)!" just because we had to ship on a certain date.  I want to ship
a kick ass 2.x release, and I honestly don't really care WHEN it happens.

Maybe July is do-able!  Help me understand the scope!

BTW, none of this has anything to do with moving the 2.x work to a
different stream than 1.x, which is what this thread is for :-)  Other than
my belief that working on 1.x and 2.x in the same stream will draw the 2.x
work out even longer than we need to.

-- 
Patrick Mueller
http://muellerware.org

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