Justin Erenkrantz wrote:
> On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> Producing some kind of definition of the remaining tree conflicts work for 1.6
>> will help the community understand what's left to do, and more importantly help
>> the tree-conflicts folks understand what's left. It may even get a few more
>> people involved if there are well-scoped bite-sized tasks available.
>>
>> Neels, Stefan, Julian, et al: I await your list of what's left. :)
>
> My suggestion from the peanut gallery is:
>
> 1) We should await a review of what is 'left' on tree conflicts
> 2) Ensure ourselves as a community that it is doable within <1 mo of work
> 3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
> 4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
> releases, but just ensuring dev@ is happy with it)
> 5) Merge approved backports and whatever is on the list of to-do for
> tree conflicts
> 6) Once tree conflicts is API-stable, begin formal stabilization procedures
>
> My point is really that we begin the stabilization of the rest of the
> code as soon as possible, get trunk back to be open (waves bye-bye to
> ra_neon *grin*), and merge tree conflicts stuff and start the final
> stabilization as soon as it's API-stable.
>
> If the tree conflicts stuff can't be resolved within 1 mo or it takes
> longer than that, then we yank the APIs for 1.6.x and it continues
> apace for 1.7.x and we release 1.6.x without it. (I'm okay with
> shipping dead code if it makes the RM process simpler as long as it
> doesn't expose any APIs.)
After talking with Karl in IRC just now, my view is kind of changing:
Let's yank the APIs now, branch 1.6.x at the end of the week, stabilize, and
release 1.6 with the currently implemented features.
We want to delay 1.6 so that people can get tree conflicts sooner, implying that
a soonish 1.6 is better than waiting a few months beyond that for 1.7. But we
forget that we've got a lot of stuff already in 1.6, some work needed to
stabilize that work, and good motivation to get that out to users right now.
I think the trepidation to yank the tree conflicts APIs for 1.6 comes from the
innate emotional attachment developers tend to have to their own code and a
desire to see it ship. I also think that there may be a voice in many people's
minds that says "we need to get tree conflicts in 1.6, because we still don't
know if our time-based releases will work out and 1.7 will be soon after 1.6."
As hokey as it sounds, we need to exercise some faith in our process, release
1.6, and know that 1.7 will be coming soon.
As a thought experiment, how difficult would it be to release 1.6 without tree
conflicts?
-Hyrum
Received on 2008-11-18 01:06:20 CET