2012/6/22 Ludovic Courtès l...@gnu.org
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial
changes (such
as minor package upgrades in Nixpkgs) can go directly into the master,
2012/6/22 Shea Levy s...@shealevy.com
I tweeted my surprise about this fact and got this response:
https://mobile.twitter.com/#!/xpaulbettsx/status/216003572163297280 . So
that might make giving more people commit access a more palatable solution.
This link is better:
Hi,
Kirill Elagin kirela...@gmail.com skribis:
Hello, this is git. Why are you against merge commits?
Automatic merge commits (when pushing something to a branch that has
been fast-forwarded in the meantime) make the history gratuitously
non-linear, and thus much harder to follow (both for
l...@gnu.org (Ludovic Courtès) writes:
Automatic merge commits (when pushing something to a branch
that has been fast-forwarded in the meantime) make the history
gratuitously non-linear, and thus much harder to follow (both
for humans and for tools like ‘git bisect’).
I typically address
there are to important points to keep in mind:
(1) we want to trust the main stable branch (whatever that is) as much
as possible
This implies that arbitrary commits should get reviewed. However simple
patches can be reviewed most efficiently by batch processing.
(2)
we want new users to
On Fri, 22 Jun 2012 03:08:21 +0400, Kirill Elagin kirela...@gmail.com wrote:
2012/6/22 Eelco Dolstra eelco.dols...@logicblox.com
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every committer actually *can* cause data loss
in the
repository.
Eelco Dolstra eelco.dols...@logicblox.com writes:
Hi all,
I've completed the migration of Nixpkgs and NixOS to GitHub. This means that
the reposities
https://github.com/NixOS/nixpkgs
and
https://github.com/NixOS/nixos
are now the official Nixpkgs and NixOS repositories,
Well, I think, those who used to have commit access to SVN should get push
access to git. And they will be accepting pull-requests into the main tree.
They have to be responsible enough to read pull-request diffs carefully
and, if needed, ask colleague for help with review (GitHub has all those
Hi Eelco,
On Jun 21, 2012, at 12:51 AM, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi all,
I've completed the migration of Nixpkgs and NixOS to GitHub.
Hooray!
Please use GitHub's integrated bug tracker. It has the advantage that you
can
refer to or close issues from commit
Hi Eelco,
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces the least
amount of administrative overhead on regular contributors
On Thu, Jun 21, 2012 at 10:59:22PM +0200, Peter Simons wrote:
Hi Eelco,
- A centralised workflow where people commit directly into the
master. This is basically what we did with Subversion. The downside
is a lack of review.
I am very much in favor of this approach because it forces
Hi!
Eelco Dolstra eelco.dols...@logicblox.com skribis:
I've completed the migration of Nixpkgs and NixOS to GitHub. This means that
the reposities
Congratulations, and thanks!
[...]
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package
Hi,
On 21/06/12 05:49, Kirill Elagin wrote:
Right now NixOS needs fast development. And small mistakes are not that fatal
—
NixOS is all about just reverting back if something goes wrong.
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every
Hi,
On 21/06/12 03:34, Mathijs Kwik wrote:
So I'm all in favor of having people just commit whatever they want
(once they've proven they somewhat know what they're doing). If others
don't like certain commits, roll them back and have some discussion.
That's the policy we've had with SVN
Hi,
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package upgrades in Nixpkgs) can go directly into the master, while
other things should be done in a branch and submitted for review. This of
course
Hi Eelco,
Noticeable part of major feature proposals get neither positive nor
negative review and get buried by inaction before the next person
who could benefit of the proposed changes appears.
That's bad, but the alternative can't be to just let everybody
potentially poor quality
2012/6/22 Eelco Dolstra eelco.dols...@logicblox.com
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every committer actually *can* cause data loss
in the
repository.
You mean force push, right? This can be solved by keeping a reference repo
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial changes
(such
as minor package upgrades in Nixpkgs) can go directly into the master, while
other things should be done in a branch
On Jun 21, 2012, at 5:30 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi,
On 21/06/12 05:49, Kirill Elagin wrote:
Right now NixOS needs fast development. And small mistakes are not that
fatal —
NixOS is all about just reverting back if something goes wrong.
One slight
19 matches
Mail list logo
