Re: Countdown to branch?

On Wed, 2004-12-29 at 23:50 +0000, Tomas Frydrych wrote:
> No, it is the fault of there not being a development branch.

        Which is exactly what I said. The problem is that we're talking past
each other because the two different subjects keep getting mixed up (-:

While we're squatting about here, you do realize that we could be
deciding on new rational criterion (other than "it didnt work, let's
just roll"), right?
I'm not, as I thought was clear, advocating another three weeks of
what's apparently the worst form of torture for you, because it's
obviously causing more problems than it's fixing. I'm merely asking
that the decision to do so be a rational, thought out, and agreed upon
one, and not something one guy does three hours after you raise issue
with the status quo, before people have had a chance to check their mail
much less weigh in on the subject. If nothing else, as martin pointed
out, the parameter's of the maintenance of the branch should be decided
upon before it happens, lest more innocent toes be stepped upon.

> That is how things where done before there was cvs, and why cvs was

I don't think it's worth explaining again why so many people still do
this all the time in projects great and small, this is going nowhere.

> invented. I have had the 'priviledge' of maintaining a patch for a
> feature for several months when I first got involved with AW and have no
> intention to do that again. The suggestion is riduculous, I hope that is
> what you meant by futily.

Several months -> exaggeration. We're talking about a couple weeks.
Maintaining -> intrustive, not benign, hence, you've lent credit back to
that same, futile, recursive argument (-:

By futily I meant that the argument would go absolutely nowhere.

> > The point of there being a branch in CVS is that it isn't private at
> > all, it's there for others to pound on, without being in the way.
>
> Do you regularly pound the ABIMATH branch? Do you regularly pound the

Does anybody regularly commit to it? Nooo... I keep a working
directory of it around and update it regularly to see if there are any
changes for me to test, and there aren't any. The bugs and
incompleteness simply are not being addressed, which is why I think I
don't want that entire branch dumped onto mainline just yet. I haven't
even heard so much as a peep out of luca about the libmathview library
separation and porting in months.

> DOUBLE branch? If I create a branch for my stuff, will you maintain a

I test it, if that's what you mean. I happen to have two working
directories of it - one I test and (believe it or not) develop in,
another that stays strictly clean in case there's ever a conflict
needing to be resolved. You'd only need one of course if you were to
put your double-dependent pango class in it (you know, hypothetically).

> local copy of it too? If the answer to any of these is 'no', then the

Yes, I'm very much interested in seeing and testing improvements in cjk
and hebrew rendering support.

> fact that they are not formaly private is of little relevance.

You said yourself that heavy infrastructural changes warrant branches,
so I'm inclined to think that any disagreement is the result of mixing
up not branching stable and branching infrastructural changes. If
someone breaks head with an infrastructural change, I start the watch on
how many hours, days, and weeks go by where HEAD is "not formaly
private" to the testers who can't build, run, or use (test) it.

> Actually, the latter has everything to do with the former if you are
> telling me 5 weeks after 2.2 release that I have to create a private
> branch to work on 2.3.

And I'm not! I just said that, multiple times! This mixing the up of
the two issues is very frustrating. If you want to branch sooner, we
need to be discussing what sooner means, and what's going as martin
pointed out to occur after the branch. We don't need to be unilaterally
taking action three hours after issue is raised, as looked to be about
to happen, that's a problem.

Do you disagree with my opinion that the decision should reflect the
database? If so, speak up and explain why it should not. Like I said,
I want rational, code/bug/data based criterion, but I'm always open to
new ideas about what that means. If all you have to say is that we need
to branch this very moment, then we need to be discussing the policies
if any that have to be agreed upon first, like martin said.

> I am glad to hear that, but that is not how the current policy is
> working out.

Yes, we've established that.

> > I'm NOT insisting on a STABLE HEAD
>
> Well, actually you are. As long as the stable is not branched there
> cannot be API changes; as long as there cannot be any API changes, the
> HEAD _is_ STABLE.

So let's quit repeating and decide on things!

        Who's going to do the branch? mg? uwog? Abbey? I would think it
would be whoever's going to maintain it (and hub's already taken his hat
out of the water wrt that, so presumably it'd be one of me and the
wogmeister). Which leads to the second question,
        Who's stable's big kahuna?
        

I would note that I agree with martin - whatever gets decided upon needs
to be consensus-approved from the top maintainer on down to the lowest
irc bot.

> Yes, I acknowledge there was a problem in the previous development
> cycle, but the solution to that is not to prevent us from working on new
> stuff by refusing to branch. The core developers have to take ownership

Delaying the branch was a proposition which was met with good cheer by
the core developers, I'm not refusing anything. That the situation has
changed as have the opinions of the developers, myself included, I've
already acknowledged, so don't waste any more time arguing it.

> of the STABLE, not just of HEAD (but that cannot be forced on us) and we
> have to agree a fixed and reasonably limited features list for 2.4 _now_

Absolutely correct.

> (I have been asking for nearly two months now, but the discussion got
> completely out of hand).

Yes, and as soon as I brought up that the list needs to be "fixed and
reasonably limited," the discussion died. I don't know what happened.
I entirely agree with you that these things need to be declared.

> > But again, I'm _not_ suggesting that HEAD be STABLE through to June.
>
> No, but from what was initially expected to be 4 weeks at most; it has
> been 5 weeks since 2.2.0 has been tagged, and you are now talking about
> another 7 weeks; that is another 3 months of nothing but bugfixing on
> the top of the the 6 months we have already done.

I am NOT now talking about another 7 weeks, I've been very clear that I
am NOT now talking about another 7 weeks, and I'm trying to get past the
point that I'am NOT now talking about another 7 weeks. To clarify, I am
NOT now talking about another 7 weeks.

Also, a note on one minor little detail - You cannot tell me that there
was 6 months of nothing but bug fixing, you know better than that. As a
single example, a feature was added on september 28th, a feature that
caused more bugs (including <scary music /> hangs), hence I cannot
accept that statement. I do not wish to discuss this, but I have to
point out the truth.

> way. Nobody has the motivation to just fix bugs any longer, I think it
> is as simple as that.

I expected this to be true about this time, but not back in november
while people were stay saying <insert quotes used in previous email>.
But again, you're obviously right, so let's just move on to more
practical discussions now.

-MG
Received on Thu Dec 30 04:45:27 2004