On Tue, Jun 05, 2012 at 09:04:33AM +0200, Micha?? G??rny wrote:
> On Mon, 4 Jun 2012 15:57:53 -0700
> Brian Harring wrote:
>
> > Btw, good catch on package.mask. Hhadn't thought of that, that
> > *will* be the most contentious point. That can be dealt w/ via
> > having git on portage-1 profil
On Mon, 4 Jun 2012 15:57:53 -0700
Brian Harring wrote:
> Btw, good catch on package.mask. Hhadn't thought of that, that
> *will* be the most contentious point. That can be dealt w/ via
> having git on portage-1 profile format so we'd have package.mask as
> directories (which Ciaran will vali
Brian Harring wrote:
> rather deal w/ that problem when it arrises, rather than trying to
> optimize for it now.
I'm strongly in favor of ripping off the bandaid, fast and hard!
Some hooks to block problematic pushes, and let people learn as
they go. It will take weeks to months for everyone to m
On Tue, Jun 05, 2012 at 12:36:04AM +0200, Michael Weber wrote:
> On 06/04/2012 03:25 PM, Brian Harring wrote:
> > While I do grok the potential issue of someone being a hog
> > (specifically via blasting commit by commit rather than building up
> > work locally, then pushing it in chunks), frankl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/04/2012 03:25 PM, Brian Harring wrote:
> While I do grok the potential issue of someone being a hog
> (specifically via blasting commit by commit rather than building up
> work locally, then pushing it in chunks), frankly... I'm not that
> c
On Mon, Jun 04, 2012 at 03:49:31AM +, Kent Fredric wrote:
> On 3 June 2012 09:46, Robin H. Johnson wrote:
> If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> >
> > All this requires, is that in the time it takes Bob to do
On Mon, Jun 4, 2012 at 2:38 PM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman wrote:
>> IMO we should try to be cutting down barriers from the git migration,
>> not throwing up more. The process has taken long enough already; the
>> desire to control everything about the m
On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman wrote:
> IMO we should try to be cutting down barriers from the git migration,
> not throwing up more. The process has taken long enough already; the
> desire to control everything about the migration is part of why it's
> taken so long.
Fair enough
On Sun, Jun 3, 2012 at 9:07 PM, Rich Freeman wrote:
> A test of some sort would cut down the risk of the unexpected when we
> do the real migration.
I understand the desire for this, but I don't think it will work. The
first few hours/days after the git migration are going to be painful
either wa
On 3 June 2012 09:46, Robin H. Johnson wrote:
If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
>
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
>
> Alice can thus
On Sun, Jun 3, 2012 at 2:21 PM, Dirkjan Ochtman wrote:
> That makes a lot of sense. There are probably a bunch of
> projects/teams where having their own branches makes some amount of
> sense; but we should really try the free-for-all at first.
So, it sounds like we have a migrated tree already.
On Sun, Jun 3, 2012 at 7:36 PM, Robin H. Johnson wrote:
>> But IMO, discussing this now is a kind of premature optimization.
> agreed, it's NOT ideal. I evaluated it as what are the potential
> problems i can foresee happening, that we haven't already discussed
> and/or solved already.
>
> I just
On Sun, Jun 03, 2012 at 06:06:03PM +0200, Dirkjan Ochtman wrote:
> I think the current Mozilla situation isn't really covered here.
Yes, I should have noted hybrids of the two models can easily exist.
> But IMO, discussing this now is a kind of premature optimization.
agreed, it's NOT ideal. I e
> On Sun, 3 Jun 2012, Dirkjan Ochtman wrote:
> But IMO, discussing this now is a kind of premature optimization.
> We should try to just do the simple thing (everyone commits to the
> main tree), and if there are too many push races we can re-evaluate
> the issue. [...]
And then what? Would r
On Sun, Jun 3, 2012 at 11:46 AM, Robin H. Johnson wrote:
> A hierarchy of merge lieutenants:
> - This is basically the Linux kernel model. The ability to merge into
> master resides with a single person, and he pulls from other known
> specified developers, who serve to collect and fix conflicts
Robin H. Johnson schrieb:
> Developer Interaction model with Git
>
> Aka, why merge lieutenants or co-ordinators might be useful
>
> This is amongst the potential problems I see might pop up.
>
> We have two developers, let's call them Alice & Bob.
>
> Alice
We may want to see if it's possible to make each ( pull & push )
transaction mutually exclusive one another (forcing repoman as git
wrapper and playing with git hooks? I don't know).
At first sight, it looks like a simple starvation problem, and there
are several anti-starvation protocols out there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/03/2012 12:22 PM, Andreas K. Huettel wrote:
> ( What I'd ask for is as "raw data" - take all commits (say, for
> the last year), filter out Manifest-only stuff, make a text file
> with only the timestamps for each commit, ideally one per line a
On Sun, Jun 03, 2012 at 12:22:01PM +0200, Andreas K. Huettel wrote:
> Am Sonntag 03 Juni 2012, 11:46:16 schrieb Robin H. Johnson:
> > If there are enough "Alice" developers, is it a possibility that Bob
> > will never have a chance to get his commit in?
> >
> > All this requires, is that in the ti
Am Sonntag 03 Juni 2012, 11:46:16 schrieb Robin H. Johnson:
> If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
>
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
We
Developer Interaction model with Git
Aka, why merge lieutenants or co-ordinators might be useful
This is amongst the potential problems I see might pop up.
We have two developers, let's call them Alice & Bob.
Alice has a nice fast internet connection, 10Mbit
21 matches
Mail list logo
