Re: [gentoo-dev] gentoo git workflow

[Rich Freeman]

hasufell <hasufell@g.o> wrote:
> * allow inconsistency and broken states as we do now with CVS (and rely
>   on QA to run a repoman tinderbox and reverse-fixing broken crap)
...
> Rich Freeman:
>> It would make a lot more sense if we had a release-oriented strategy,
>> even if releases were hourly/daily/etc.
>>
>
> If we are going that way, then we should think over the whole branching
> model. I have a few things in mind, but I think we are already
> fine-tuning stuff here that can still be fine-tuned later.

Apologies for replying to two different emails in one here, but these
are related for the purpose of this reply.

I'm all for proposals to improve the way Gentoo works.  However, part
of the reason that the git migration keeps on never happening is that
there is this general desire out there to tie it to some kind of
complete transformation in how we operate.

Today, we don't have the same kind of tree-consistency you're
advocating.  So, moving to git without achieving this kind of
consistency is not a regression.

Today, we don't have some kind of completely airtight
everything-is-gpg-signed secure code flow.  So, moving to git without
achieving that is also not a regression.

If we want to have a discussion around whether Gentoo would be better
off if we were more release-based (even if those releases were
frequent/automated/etc), or about how to improve the security of our
code base, I think those would be very healthy discussions to have.
However, I don't think we should tie them to the git migration.

Simply moving to git while keeping just about everything else the same
will be a fairly disruptive change, and as we've already seen in this
thread there are some who just prefer cvs (though I think they're in
the minority by far).  If we try to make several other big changes at
the same time I just think that it will never happen.

I suggest we just get git working in a fashion that is "good enough."
I think that will already bring an increased level of consistency
compared to our current cvs workflow, where people run repoman from
cvs checkouts where you can't even ensure that any two devs have quite
the same trees at the same time.

There is nothing that keeps us from moving from that model to one that
is more revolutionary at another time.  However, trying to do it all
at once probably means that none of us get anything we're looking for,
because we're not going to do it with cvs and we'll never get off of
cvs unless simply doing that by any means necessary is the imperative.

--
Rich