On Mon, Nov 17, 2008 at 7:05 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> 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?
This sounds premature ... in the sense that you want to make a drastic
decision without giving us a chance to know all the options. The
remaining work might be manageable, or it might be possible to just
rip out a part of it where most of the remaining issues lie and still
deliver some of the value now in 1.6. The similarity that I see with
1.5 is that we have a group of developers that are taking a lot of
time to explain the current state and ask the rest of us for opinions
on things like UI etc. and not getting a lot of feedback from anyone
outside their circle. We want them to just tell us everything is good
without looking at what they have done.
In some of the limited tests I have run with the feature it seems to
work pretty well at its core function of identifying tree conflicts.
It gets confusing knowing what to do next, but I have a feeling we
could wait until 1.8 and this confusion is not going to go to away.
Conflicts are difficult. If they weren't, then the tool would just
resolve them. I do not think we'll ever have some single magic UI you
use to resolve a tree conflict. What I have focused on is whether it
keeps the WC in a valid state and whether we provide the user the
tools (subcommands) to work with it. It seems to be getting better.
If we completely wait for 1.7 then we are going to be faced with some
of the problems we had in 1.5 in that we will have at least two and
possible three big features all landing at once. This could be good
... if the tree conflicts API is not locked down and the WC is being
rewritten than we do not have to live with any bad decisions. This
could be bad ... in that we underestimate how much the intersection of
these two features slow each other down and get in each others way.
This happened with sparse directories and merge tracking and could
happen here.
Anyway, I am not against the idea but would still like to hear more
about what our options are. It does not seem like a productive usage
of our time to spend a few weeks ripping out work that has been going
for most of the year. And then have to turn around and put it back --
if we have other options. I agree we ought not wait another four to
six weeks to branch.
Finally, I am starting to think I agree with Greg that we ought to
stabilize on trunk and then branch and do an RC. After seeing your
paper on the 1.5 release it seems like the releases where things went
the smoothest that is exactly what happened, and the ones where we
branched and then stabilized are the ones that took forever to finish.
If you consider this recent tree conflicts work part of the
stabilization then we are not really doing that bad.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 01:57:51 CET