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
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
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 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 #
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
-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
(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: 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" ]] && : $
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
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
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
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
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
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
-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
-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
>
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
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, 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
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
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
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
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
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
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 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
34 matches
Mail list logo
