On Sat, 02 Jun 2012 18:04:41 -0700
Zac Medico wrote:
> #!/usr/bin/env bash
> named_pipe=$(mktemp -d)/fifo
>
> (
> # hold the pipe open in read mode, so
> # the writer doesn't block
> sleep 3
> ) < "$named_pipe" &
I don't understand this part. This keeps the pipe open for readi
On 06/03/2012 12:15 AM, Michał Górny wrote:
> On Sat, 02 Jun 2012 18:04:41 -0700
> Zac Medico wrote:
>
>> #!/usr/bin/env bash
>> named_pipe=$(mktemp -d)/fifo
>>
>> (
>> # hold the pipe open in read mode, so
>> # the writer doesn't block
>> sleep 3
>> ) < "$named_pipe" &
>
> I don'
On Sat, 02 Jun 2012 20:32:36 -0400
James Cloos wrote:
> What's up with md5-cache?
>
> Every syn has to pull the entire md5-cache hierarchy over again, as if
> some daemon re-creates every file every day, rather than only
> re-writing those files which need updates and adding/removing those
> whi
This is one of several braindumps I've got, getting what are potentially
very important details about the Git stuff out of my head, so that it
doesn't matter if I become hit by a bus. Apologies if this mail seems a bit
scrambled, per -core, my brain is rather scrambled lately.
TL;DR:
--
I prop
Michał Górny posted on Sun, 03 Jun 2012 09:22:04 +0200 as excerpted:
>> Even if only the files metatdata changes, that still adds a significant
>> cost to an rsync.
>
> I wonder when it will come to the point where git will be more efficient
> than rsync. Or maybe it would be already?
Handwavey
Robin H. Johnson posted on Sun, 03 Jun 2012 08:18:24 + as excerpted:
> This is one of several braindumps I've got, getting what are potentially
> very important details about the Git stuff out of my head, so that it
> doesn't matter if I become hit by a bus.
Thanks. Along with the bus factor
On Sun, Jun 03, 2012 at 08:31:43AM +, Duncan wrote:
> Micha?? G??rny posted on Sun, 03 Jun 2012 09:22:04 +0200 as excerpted:
>
> >> Even if only the files metatdata changes, that still adds a significant
> >> cost to an rsync.
> > I wonder when it will come to the point where git will be more
On Sun, 3 Jun 2012 09:25:43 +
"Robin H. Johnson" wrote:
> On Sun, Jun 03, 2012 at 08:31:43AM +, Duncan wrote:
> > Micha?? G??rny posted on Sun, 03 Jun 2012 09:22:04 +0200 as
> > excerpted:
> >
> > >> Even if only the files metatdata changes, that still adds a
> > >> significant cost to a
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
On Sun, Jun 03, 2012 at 11:34:07AM +0200, Micha?? G??rny wrote:
> I means using separate proto for metadata, not necesarrily git. In any
> case, if it comes to transferring a lot of frequently-changing files,
> rsync is not that efficient...
It does NOT send any of the intermediate states.
So the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/03/2012 09:18 AM, Robin H. Johnson wrote:
> This is one of several braindumps I've got, getting what are
> potentially very important details about the Git stuff out of my
> head, so that it doesn't matter if I become hit by a bus. Apologies
>
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
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
-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
Am Sonntag 03 Juni 2012, 10:18:24 schrieb Robin H. Johnson:
> I propose:
> - merges are explicitly allowed, even non-fast-forwards
> - all commits MUST be signed
> - if you include a commit from a user:
> author := non-@gentoo
> committer := @gentoo
> signer := $committer
>
Sounds reasonabl
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
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
On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
wrote:
> Sounds reasonable given the current state of git. Let's just be clear about
> the following consequence (I hope I understand this correctly):
>
> * User makes signed improvements in gentoo-x86 clone
> * Developer pulls from user and >mer
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
> 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 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, 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 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.
Am Sonntag 03 Juni 2012, 18:01:04 schrieb Dirkjan Ochtman:
> On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
>
> wrote:
> > Sounds reasonable given the current state of git. Let's just be clear
> > about the following consequence (I hope I understand this correctly):
> >
> > * User makes sig
For removal in 30 days.
# Andreas K. Hüttel (03 Jun 2012)
# Not maintained well in Gentoo for a long time. Better support
# for zeroconf is available via net-dns/avahi[mdnsresponder-compat]
# - please use that instead. mDNSResponder will be removed soon.
net-misc/mDNSResponder
--
Andreas K. H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2012 10:08 PM, Mike Frysinger wrote:
> # @FUNCTION: _multijob_fork # @INTERNAL # @DESCRIPTION: # Do the
> actual book keeping. _multijob_fork() { [[ $# -eq 1 ]] || die
> "incorrect number of arguments"
>
> local ret=0 [[ $1 == "pre" ]] && : $
(re-send without enigmail screwing up the code formatting)
On 06/02/2012 10:08 PM, Mike Frysinger wrote:
> # @FUNCTION: _multijob_fork
> # @INTERNAL
> # @DESCRIPTION:
> # Do the actual book keeping.
> _multijob_fork() {
> [[ $# -eq 1 ]] || die "incorrect number of arguments"
>
> local
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
# Markos Chandras (04 Jun 2012)
# Dead upstream. Security problems. Bug #249112
# Removal in 30 days
net-misc/ptrtd
- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-06-03 23h59 UTC.
Removals:
x11-apps/xsetmode 2012-05-28 13:22:51 scarabeus
x11-apps/xsetpointer2012-05-28 13:22:51 scarabeus
sys-kernel/m
On 06/02/2012 10:08 PM, Mike Frysinger wrote:
> # @FUNCTION: redirect_alloc_fd
> # @USAGE: [redirection]
> # @DESCRIPTION:
> # Find a free fd and redirect the specified file via it. Store the new
> # fd in the specified variable. Useful for the cases where we don't care
> # about the exact fd #
No objections and 2x +1, so I will commit virtual/awk to ~arch and
app-admin/eselect-awk to ~arch & masked for testing.
Please port packages to virtual/awk (if possible) and make bug reports
block on the awk porting tracker (bug #418473).
2012/5/29 Christoph Junghans :
> Hi,
>
> recently I stumb
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 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 Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel wrote:
> However, then the "committer" of the contributed commits before the merge is
> then the user, I guess?
>
> (The rule meaning as suggested by Robin
>> - if you include a commit from a user:
>> author := non-@gentoo
>> committer := @gen
34 matches
Mail list logo
