Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Portage Git migration - clean cut or git-cvsserver

 

 

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


vitorbrandao.pt at gmail

May 24, 2012, 2:16 AM

Post #51 of 163 (303 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

2012/5/24 Dan Douglas <ormaaj [at] gmail>

> On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
> > Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
> > > On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> > >> On Wed, 23 May 2012 16:14:53 -0500
> > >>
> > >> Dan Douglas <ormaaj [at] gmail> wrote:
> > >> > If not I will be leaving Gentoo for Funtoo in the near future,
> though
> > >> > there are disadvantages to doing this I don't look forward to
> dealing
> > >> > with.
> > >>
> > >> Most of us will probably be doing that :P.
> > >
> > > Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo
> > > boxen to deal with. I just need to be able to use git on the tree (even
> > > without the full history is perfectly fine) to ease the difficulty of
> > > local overlay management. Glad to hear that will be possible, or at
> > > least somewhat easier.
> >
> > FWIW, I as a user would sure like a git-based tree. Doing git
> whatchanged
> > searches on individual files and being able to track my last checkout and
> > roll back to it, or to a point between it and current HEAD, are extremely
> > useful. I haven't thought of it much until now, but I think maintaining
> > overlays as simple branches would be great, as well.
>
> I don't think doing a branch of the entire tree is a good idea (well
> maybe...). I was thinking more along the lines of subtree merges into a
> local
> overlay, or perhaps submodules. To do that currently (I think) would
> require
> taking the rsync tree and putting that into a repo, and trying to keep it
> synchronized. Plus in the process you lose all correspondance with upstream
> commits so that logs and diffs become meaningless.
> --
> Dan Douglas


git++

--
Vítor Brandão (noisebleed)


kentfredric at gmail

May 24, 2012, 3:02 AM

Post #52 of 163 (303 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 24 May 2012 05:35, Alexey Shvetsov <alexxy [at] gentoo> wrote:
> Full clone will be about 1G or so but no more then 2. If we will drop
> changelog it will be much smaller
>

And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligible. :D


--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


kentfredric at gmail

May 24, 2012, 3:08 AM

Post #53 of 163 (305 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 24 May 2012 08:32, Rich Freeman <rich0 [at] gentoo> wrote:
>
> Sure.  The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
>
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases the amount of pain
> our end-users run into due to the mistake, which leads to lots of
> flame wars on -dev.  That means that the guy who made the mistake is
> subjected to more public ridicule, and is less likely to do it again,
> That improves quality too.
>
> Since cvs doesn't tie together tree-wide changes in a nice way or
> allow them to be transactionally completed, individual package
> maintainers don't need to be as concerned with the big picture view.
> Now as the maintainer of libfoo the fact that somebody changed my
> ebuild without making a corresponding change in some profile is
> completely hidden from me, and I can go to sleep peacefully without
> realizing that my users are all going to have horribly broken systems
> in the morning.  Blissful ignorance of end-user suffering improves
> developer morale, and helps get rid of pesky users at the same time.
>
> cvs also makes more more aware of what is going on around me.  Anytime
> I want to work on something in parallel with the main development
> branch I get to manually merge changes in, which keeps me aware of my
> place in the world.  That means that I'm less likely to build nice new
> features, which means fewer bugs, which improves quality, and may even
> drive away users as an added bonus!
>
> See, cvs is really the wave of the future!
>
> Rich
>


<meta name="sarcasm" value="on" />

This CVS stuff sounds a bit too uppity and unstable to me, sounds like
we should go back to the tried and true code collaboration by
date-stamped tarballs of the tree which are centralised once a week to
a master tarball.



--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


alexxy at gentoo

May 24, 2012, 3:16 AM

Post #54 of 163 (306 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Kent Fredric писал 2012-05-24 13:02:
> On 24 May 2012 05:35, Alexey Shvetsov <alexxy [at] gentoo> wrote:
>> Full clone will be about 1G or so but no more then 2. If we will
>> drop
>> changelog it will be much smaller
>>
>
> And if you use git commit signing instead of ebuild manifests,
> intra-commit churn will almost be negligible. :D

Yep. Each signature to manifest adds ~512B of echanged data. And this
will be added every commit. Also Manifest contain checksumms for all
filesincluding ebuild, patches, metadata and so on. thin-manifests will
contain only DIST data so they will be much smaller
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


kentfredric at gmail

May 24, 2012, 3:17 AM

Post #55 of 163 (305 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 24 May 2012 09:48, Michael Weber <xmw [at] gentoo> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/23/2012 11:14 PM, Dan Douglas wrote:
>> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>>> 2. rsync generation is NOT going away. Users will still be using
>>> it.
>
> First, I'd stick with the current rsync to spread the tree (mirror
> work and mirrors+regular rsync users shouldn't notice any backend
> switch at all).
>
>
>> Would users have a way of gaining read-only access? This would be
>> EXTREMELY helpful.
> Sure, this would be possible like any other git checkout
> (layman-git-overlays, github.com, etc.).
>
> Please compare (browsing source and access description)
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git
>
>
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
> xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
> =dvFZ
> -----END PGP SIGNATURE-----
>


I think there should most definitely be an official github mirror of
the main tree, just a "read-only" mirror from githubs perspective.

Just how to best do the mirroring is the question

a) Replicate to github when a user does 'push' with a server-side push hook?
( Downside: if github goes down, gentoo devs will see it when
they push, and pushing takes longer because the output from the
replicated push is delivered to the original dev )

b) Daemonized hook that monitors for changes in the master repo, and
replicates commits to github after each push

c) Tie it with the rsync tree building system so every time the tree
is built for rsync clients, the master is replicated to github.


Also, this should obviously be force-pushed, so any branch rebases on
the master repo are replicated to the github mirror properly.
--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


1i5t5.duncan at cox

May 24, 2012, 4:43 AM

Post #56 of 163 (305 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Dan Douglas posted on Thu, 24 May 2012 01:51:28 -0500 as excerpted:

> I don't think doing a branch of the entire tree is a good idea (well
> maybe...). I was thinking more along the lines of subtree merges into a
> local overlay, or perhaps submodules. To do that currently (I think)
> would require taking the rsync tree and putting that into a repo, and
> trying to keep it synchronized. Plus in the process you lose all
> correspondance with upstream commits so that logs and diffs become
> meaningless.

The thing about git branches is that they cost almost nothing. If the
whole main tree is a single git tree, and you already have that
available, maintaining a branch consisting of what we now call an overlay
is trivial, compared to simply maintaining the separate files, as is
normally done now.

In that regard, git is nothing like for instance svn, where branches come
at a much higher cost, as does merging between them. (CVS... I don't
actually know enough about to make an informed comparison.

It'd be a real shame not to expose the read-only git tree to the users
who want it. Git was /designed/ to be distributed in that manner.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman


djc at gentoo

May 24, 2012, 5:05 AM

Post #57 of 163 (307 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan [at] cox> wrote:
> In that regard, git is nothing like for instance svn, where branches come
> at a much higher cost, as does merging between them.

That's wrong. SVN branches are just about as cheap as git branches,
although merges used to be much more painful. I'm not sure how good
merging in recent SVN is.

Let's please stay a little on-topic? The migration will get there much
faster if we don't succumb to feature creep.

Cheers,

Dirkjan


ciaran.mccreesh at googlemail

May 24, 2012, 6:03 AM

Post #58 of 163 (303 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, 24 May 2012 14:05:50 +0200
Dirkjan Ochtman <djc [at] gentoo> wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan [at] cox> wrote:
> > In that regard, git is nothing like for instance svn, where
> > branches come at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as cheap as git branches,

[citation needed]

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


kentfredric at gmail

May 24, 2012, 6:37 AM

Post #59 of 163 (304 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 25 May 2012 00:05, Dirkjan Ochtman <djc [at] gentoo> wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan [at] cox> wrote:
>> In that regard, git is nothing like for instance svn, where branches come
>> at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as cheap as git branches,
> although merges used to be much more painful. I'm not sure how good
> merging in recent SVN is.

Cheapness ... maybe in binary disk utilization ( need an actual
comparison here I think ), but in cognitive overheads, I'd argue git's
branching system is definitely cheaper. Going from Git back to SVN,
the mentality of "copy a directory and you have a new branch!!!" seems
a bit crazy.

And switching between branches in-place at a fixed disk location is
definitely cheaper ( mentally at least ) than SVN.

I hope I never have to use svn switch again :/
--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


xmw at gentoo

May 24, 2012, 6:51 AM

Post #60 of 163 (302 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:37 PM, Kent Fredric wrote:

Kent, this is of topic, stop it.

- --
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++PO8ACgkQknrdDGLu8JC2cAD/WknV6DJEzYEsuXJD0TuDU99I
arDTkrBHNXydYVdaxGoBAJmmVm3o7YWlMAvFBz2Eu4ma/VXEHdqocFwl0NK+FEAh
=Esu3
-----END PGP SIGNATURE-----


mgorny at gentoo

May 24, 2012, 7:40 AM

Post #61 of 163 (303 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, 24 May 2012 22:17:20 +1200
Kent Fredric <kentfredric [at] gmail> wrote:

> On 24 May 2012 09:48, Michael Weber <xmw [at] gentoo> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 05/23/2012 11:14 PM, Dan Douglas wrote:
> >> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
> >>> 2. rsync generation is NOT going away. Users will still be using
> >>> it.
> >
> > First, I'd stick with the current rsync to spread the tree (mirror
> > work and mirrors+regular rsync users shouldn't notice any backend
> > switch at all).
> >
> >
> >> Would users have a way of gaining read-only access? This would be
> >> EXTREMELY helpful.
> > Sure, this would be possible like any other git checkout
> > (layman-git-overlays, github.com, etc.).
> >
> > Please compare (browsing source and access description)
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
> > http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git
> >
> >
> > - --
> > Gentoo Dev
> > http://xmw.de/
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.17 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
> > xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
> > =dvFZ
> > -----END PGP SIGNATURE-----
> >
>
>
> I think there should most definitely be an official github mirror of
> the main tree, just a "read-only" mirror from githubs perspective.
>
> Just how to best do the mirroring is the question
>
> a) Replicate to github when a user does 'push' with a server-side
> push hook? ( Downside: if github goes down, gentoo devs will see it
> when they push, and pushing takes longer because the output from the
> replicated push is delivered to the original dev )
>
> b) Daemonized hook that monitors for changes in the master repo, and
> replicates commits to github after each push
>
> c) Tie it with the rsync tree building system so every time the tree
> is built for rsync clients, the master is replicated to github.

d) Talk with github folks to add our repo as 'mirror'.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


sera at gentoo

May 24, 2012, 8:02 AM

Post #62 of 163 (303 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, 24 May 2012 16:40:02 +0200
Michał Górny <mgorny [at] gentoo> wrote:

> d) Talk with github folks to add our repo as 'mirror'.

Can we keep the master on Gentoo hardware please.

Also, there still should be a bug at b.g.o and git format-patch works
just fine for that. Maybe it's only github now but how many places is a
developer supposed to monitor?
Attachments: signature.asc (0.48 KB)


rich0 at gentoo

May 24, 2012, 8:32 AM

Post #63 of 163 (309 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser <sera [at] gentoo> wrote:
> Can we keep the master on Gentoo hardware please.
>
> Also, there still should be a bug at b.g.o and git format-patch works
> just fine for that. Maybe it's only github now but how many places is a
> developer supposed to monitor?

I'm actually a little torn on this one. I'm fine with keeping the
"master" on Gentoo in the sense that this is where the rsync tree gets
generated. However, gitbub has a lot of tools like pull requests that
could potentially improve workflow, especially for things like proxy
maintainers. So, letting those teams work more outside of Gentoo and
just push their changes into Gentoo might make sense.

Perhaps github should be viewed as a widely-shared overlay that gets
automatic updates from the main tree in the master branch (or whatever
we call it). You can work on a branch in github, get it where you
want it to be, and then push it to Gentoo pretty easily. When I don't
have access to an upstream repository I often just push a copy to a
fork on Github just to make my own life easier.

Rich


mgorny at gentoo

May 24, 2012, 8:40 AM

Post #64 of 163 (301 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thu, 24 May 2012 17:02:24 +0200
Ralph Sennhauser <sera [at] gentoo> wrote:

> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny <mgorny [at] gentoo> wrote:
>
> > d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.

Yes, that's the intent. I'm just saying that github seems to have
a hidden feature of mirroring external repos.

https://github.com/mirrors

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


ultrabug at gentoo

May 24, 2012, 9:17 AM

Post #65 of 163 (306 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 24/05/2012 03:19, Mark Wright wrote:
> Michael Weber <xmw [at] gentoo> writes:
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive load).
>
> +1 for clean cut to git
>

clean cut +1


kentfredric at gmail

May 24, 2012, 10:13 AM

Post #66 of 163 (303 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 25 May 2012 03:02, Ralph Sennhauser <sera [at] gentoo> wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny <mgorny [at] gentoo> wrote:
>
>> d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.

Definitely. But having a mirror on github will increase forkability,
and will make it much faster for people to get started on
contribution.

When the user has their tree up to how they want it, they can either
send a pull request to another gentoo dev who also has a fork on
github, or send a link to the commit via some medium ( bug tracker ? )
, and some dev can just add that as a remote, and merge/cherry-pick
the commits they want..

In my books, github is mostly a marketing and ease of access platform
that streamlines the ability for people to get started contributing
and facilitate easy distribution of changes back to upstream.

But this is mostly side topic.

CLEAN CUT++

If there are problems with it, we can address those when we know what
they are, not when we're inventing problems that might not actually
exist due to conjecture.

I haven't encountered any "real" problems yet in size or performance
constraints with perl-experimental . Sure, its not portage, its only
~800 packages vs portages 15000 , but it should be a somewhat
reasonable synthetic workload.

Side note: I assume, that there is, a way, if you *really* need it, to
copy all the new git commits back to the cvs tree if something
critically broken in git turns up so bad it has to be dropped. I think
it unlikely, but knowing there is a way to "go back" would give much
reassurance.

--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


axs at gentoo

May 24, 2012, 10:52 AM

Post #67 of 163 (304 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/05/12 01:13 PM, Kent Fredric wrote:
> On 25 May 2012 03:02, Ralph Sennhauser <sera [at] gentoo> wrote:
>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>> <mgorny [at] gentoo> wrote:
>>
>>> d) Talk with github folks to add our repo as 'mirror'.
>>
>> Can we keep the master on Gentoo hardware please.
>
> Definitely. But having a mirror on github will increase
> forkability, and will make it much faster for people to get started
> on contribution.
>
> When the user has their tree up to how they want it, they can
> either send a pull request to another gentoo dev who also has a
> fork on github, or send a link to the commit via some medium ( bug
> tracker ? ) , and some dev can just add that as a remote, and
> merge/cherry-pick the commits they want..
>


...is this something we (as the developer base) WANT non-dev's to be
able to do?? I would expect we'd want the tree to still be treated as
read-only-not-modifyable by the rest of the gentoo/linux community,
otherwise we're going to have a rather large mess on our hands
(multiple forks of the main tree != a uniform main tree + overlays,
the way it does now)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk++dWAACgkQ2ugaI38ACPBBpAD9EaJsSNXMS6bDbttJStVqghlO
Q46xkgPIgunriOLJhDoA/06HH/kgXd/Qrq/Ex0X3kV9nDmYqE0OmiFM1kVTfdVCD
=dcOs
-----END PGP SIGNATURE-----


ciaran.mccreesh at googlemail

May 24, 2012, 11:08 AM

Post #68 of 163 (304 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 24 May 2012 13:52:32 -0400
Ian Stakenvicius <axs [at] gentoo> wrote:
> > When the user has their tree up to how they want it, they can
> > either send a pull request to another gentoo dev who also has a
> > fork on github, or send a link to the commit via some medium ( bug
> > tracker ? ) , and some dev can just add that as a remote, and
> > merge/cherry-pick the commits they want..
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

That's only a problem if you don't merge things quickly. Encouraging
users to submit git format-patches or merge requests is a great way of
reducing developer workload.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk++eQMACgkQ96zL6DUtXhF4kgCfZkdR7RTvUUlFdTgdNkyDHwGK
NlgAoKgSUKEWN6WnrihawHkhhrPbJlv2
=8RdD
-----END PGP SIGNATURE-----


kentfredric at gmail

May 24, 2012, 11:17 AM

Post #69 of 163 (304 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

Yes, we want them to.

There is still going to be a "master" authoritative tree, forks of
that tree will exist for the purpose of adding new ebuilds to the
master tree / bumping existing packages.

If your worry is "There are copies of gentoo /usr/portage out there
that aren't GIT HEAD" , then stop worrying, as thats already the case.

As soon as somebody modifies a file in their local /usr/portage, that
happens, and as soon as a users portage tree gets older than 1 hour,
that happens.

And if your worry is "But they could be replicating it in that form",
then don't worry, they could already be doing that, nothing is
stopping people from re-providing their full (tweaked) /usr/portage
via rsync to others. In fact, if you're running in a network with a
network master, you're doing that to an extent.

But those sources are not official, and have no utility outside
development/private use scenarios, and thus, don't compete with
overlays directly.

Sure, you *could* make something like an overlay by forking gentoo
master and then maintaining that, but it would be impractical, and
you'd be better off using a plain overlay ( less noise ), or using
that fork for the purpose of getting things in master.

You /could/ do a long-lived public maintained fork, and then you'd be
Sabyon / Funtoo.

Doing this has its own difficulties, but I think long term, enabling
this is good:

Sabyon/Funtoo can fork gentoo on github, and then any improvements
made on their forks, gentoo can easily steal back, and its easier to
track the differences between them. Win/Win in my books.

Summarised:

Yes, its a good idea.
No, we shouldn't try stopping them.
Actually, really can't stop them, its already happening, Git will just
make the workflow better on top of it.

--
Kent

perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


hwoarang at gentoo

May 24, 2012, 11:33 AM

Post #70 of 163 (304 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/24/2012 06:52 PM, Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
>> On 25 May 2012 03:02, Ralph Sennhauser <sera [at] gentoo> wrote:
>>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>>> <mgorny [at] gentoo> wrote:
>>>
>>>> d) Talk with github folks to add our repo as 'mirror'.
>>>
>>> Can we keep the master on Gentoo hardware please.
>
>> Definitely. But having a mirror on github will increase
>> forkability, and will make it much faster for people to get
>> started on contribution.
>
>> When the user has their tree up to how they want it, they can
>> either send a pull request to another gentoo dev who also has a
>> fork on github, or send a link to the commit via some medium (
>> bug tracker ? ) , and some dev can just add that as a remote,
>> and merge/cherry-pick the commits they want..
>
>
>
> ...is this something we (as the developer base) WANT non-dev's to
> be able to do?? I would expect we'd want the tree to still be
> treated as read-only-not-modifyable by the rest of the gentoo/linux
> community, otherwise we're going to have a rather large mess on our
> hands (multiple forks of the main tree != a uniform main tree +
> overlays, the way it does now)
>
>
Why do you care? If someone uses a forked tree then he and his users
are on their own. However, I would like to have the ability to accept
pull requests from users and then push my local tree back to the
"official" one.

- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPvn8KAAoJEPqDWhW0r/LCjVMP/jdZ+f96hx3zF25XIfn5xKdg
jsPO1kQ7KLMLFg+ZxhDMYo/ORbbOuuqtyBA9pnoDYgSB9xSQ5ETIemsyoL6MHMmj
7DGyUkd0HUFIROjaEDCD0BipPyY5Cpj/D2Ep9br0o4mfXTi2qVg5sE8qVsjguVf5
3tZ1GEm8w4k8UIj39pICX5o9X35nTlG6gkQh2cy6ZO3+MHBmyt3WOzmRczrW4bgX
kcMprYYdqoHd/VcC4LJoKMO8ALlX7UdsU2Yoe68ImKvdSdhxdqla9qPqUmf2kqqE
DYZoYnu1+NI5CtN2d30Ut0ewUqP/9/kKb0Gx/QKZkD9DR+jAv75O0M/PM3MpVP/P
wxUVRzmv48WNXJmahqiv1fiBbWR4Al5KXIfk8g49oPxNjDFb00ij0G0YSxfbvbih
kEZl24hiqumO+oLdJOGhQTbeFDDDtnJuT8Ft9914FW77dWt9M/B61udlaS5B4E41
rgP5kHVb3wmbPcS8uc8YklceJfog3FVUzghTzH9swz9umSSmO1B6JGOVKFBuyTCY
MNGn9Oz+n/Vklbg63br4AIsyokpTbGx3coeTJzQ3Jry97l5L3+TlJFqk9I644cIs
cqsh575aAlHyakvZfWdIgbBschcsRWTRuzaZAeTW4qnMMVhMn19nTkgoSCyu2PEp
Qq32ezdYxEpv4a3X40M6
=m1ok
-----END PGP SIGNATURE-----


ormaaj at gmail

May 24, 2012, 11:37 AM

Post #71 of 163 (305 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
> > On 25 May 2012 03:02, Ralph Sennhauser <sera [at] gentoo> wrote:
> >> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
> >>
> >> <mgorny [at] gentoo> wrote:
> >>> d) Talk with github folks to add our repo as 'mirror'.
> >>
> >> Can we keep the master on Gentoo hardware please.
> >
> > Definitely. But having a mirror on github will increase
> > forkability, and will make it much faster for people to get started
> > on contribution.
> >
> > When the user has their tree up to how they want it, they can
> > either send a pull request to another gentoo dev who also has a
> > fork on github, or send a link to the commit via some medium ( bug
> > tracker ? ) , and some dev can just add that as a remote, and
> > merge/cherry-pick the commits they want..
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,

Of course it's read only - just like all other public repositories. You don't
want to accept improvments? I don't understand this.

> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

Forking happens when it's hard to contribute. You even want to make overlays
difficult? The only real mechanism Gentoo provides for user extensibility?
--
Dan Douglas
Attachments: signature.asc (0.19 KB)


mschiff at gentoo

May 24, 2012, 12:51 PM

Post #72 of 163 (305 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny:
> On Wed, 23 May 2012 14:42:37 +0200
>
> Michael Weber <xmw [at] gentoo> wrote:
> > *if you still read this* *wow*
> >
> > Please discuss my arguments and come to the conclusions to
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> > this bug from the blockers of "[TRACKER] portage migration to git".
>
> Kill it! And while we're at it, kill ChangeLogs as well!
>
> /me hides...

with "git log some-cat/foo" we will have it automagically.

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134
Attachments: signature.asc (0.19 KB)


ormaaj at gmail

May 24, 2012, 12:57 PM

Post #73 of 163 (302 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

> On 24/05/12 02:37 PM, Dan Douglas wrote:
> > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:

> >
> > Of course it's read only - just like all other public
> > repositories. You don't want to accept improvments? I don't
> > understand this.
>
> I have no problem with accepting improvements, i'm just leary of
> semi-official copies of the tree that could be checked out and checked
> into by non-dev's (this said, I don't know that much about git but I
> assume that github users could commit to the github copy yes? that
> being the way users would contribute?)

> >> otherwise we're going to have a rather large mess on our hands
> >> (multiple forks of the main tree != a uniform main tree +
> >> overlays, the way it does now)
> >
> > Forking happens when it's hard to contribute. You even want to
> > make overlays difficult? The only real mechanism Gentoo provides
> > for user extensibility?
>
> Nono, I was comparing the (from my perspective) mess of multiple forks
> of the main tree that hosting on github/other services could
> potentially enable, with a single uniform source of the main tree plus
> overlays for extended contribution (which is the system we have now).

Git is about decentralized version control. When you clone a repo, you have
your own "fork". When everyone has their own branch, everyone is effectively
equal. So yes you can expect much much more forking. In Git land, forks are
good. There's no way to enforce that people only pull from some "official"
source.

It works out in practice so that 99% of the time people only care about a
couple branches of one repository. Counterintuitively, this comes as a side-
effect of git actually doing distribution properly and making it easier for
everybody's workflow. The overlay model by contrast is quite broken on its own
and virtually forces creation of new overlays in order to make changes without
the benifits of version control (with regards to the rsync tree at least).

What Github does is facilitate making it easy to fork/branch and provide a
central way to push changes back into a remote through pull requests. Pull
requests and other web services around git hosting are pretty much the thing
that makes github worth using. From the standpoint of accepting patches, the
differenc e to you is rather than (or in addition to) accepting patches through
bugzilla, you can choose to accept a push directly from someone else's copy of
the repo. It isn't like a wiki - everybody commits to their own repositories
and pushing to a remote is on a whitelist basis just like in centralized
version control.

Anyway, others are better at "selling" Git than I and there are no shortage of
resources out there describing distributed development models. I think this
thread is supposed to be about the technical hurdles and it looks like whether
or not it's feasible to support github. I can't really comment on the
latter. Aside from whatever hoops the Gentoo devs have to jump through in
trying to maintain multiple repos, it's hard to see the downsides to using
github in and of itself.

Talk to the Gentoo Haskell guys, they've been using Github for some time. And
if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o

--
Dan Douglas
Attachments: signature.asc (0.19 KB)


titanofold at gentoo

May 24, 2012, 2:00 PM

Post #74 of 163 (303 views)
Permalink
Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:57 PM, Dan Douglas wrote:
> Git is about decentralized version control. When you clone a repo,
> you have your own "fork". When everyone has their own branch,
> everyone is effectively equal. So yes you can expect much much
> more forking. In Git land, forks are good. There's no way to
> enforce that people only pull from some "official" source.
>
> It works out in practice so that 99% of the time people only care
> about a couple branches of one repository. Counterintuitively, this
> comes as a side- effect of git actually doing distribution properly
> and making it easier for everybody's workflow. The overlay model by
> contrast is quite broken on its own and virtually forces creation
> of new overlays in order to make changes without the benifits of
> version control (with regards to the rsync tree at least).
>
> What Github does is facilitate making it easy to fork/branch and
> provide a central way to push changes back into a remote through
> pull requests. Pull requests and other web services around git
> hosting are pretty much the thing that makes github worth using.
> From the standpoint of accepting patches, the differenc e to you is
> rather than (or in addition to) accepting patches through bugzilla,
> you can choose to accept a push directly from someone else's copy
> of the repo. It isn't like a wiki - everybody commits to their own
> repositories and pushing to a remote is on a whitelist basis just
> like in centralized version control.

This gets us into another topic altogether.

I do believe git pull-requests should go through Bugzilla. A
pull-request is the equivalent to bump requests, patch fixes, and all
sorts of stuff that we already handle through Bugzilla. Bugzilla also
contains our history.

If they happen to be needing to be pulled from github, that's fine.
Definitely convenient for the contributor.

We'll also need to clearly document how the pull-request is to be
generated. (I vote for requiring signed pull-requests. [1])

github should not be our central point of contact. We have b.g.o for
that. github should be on the fringes as a tool that we can use if we
want to.

[1]
http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
=MVyV
-----END PGP SIGNATURE-----


alexxy at gentoo

May 24, 2012, 2:14 PM

Post #75 of 163 (306 views)
Permalink
Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver) [In reply to]

In gentoo git tree all git commits will be signed by commiter gpg keys
(and this will be requerd!)

Aaron W. Swenson писал 2012-05-25 00:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/24/2012 03:57 PM, Dan Douglas wrote:
>> Git is about decentralized version control. When you clone a repo,
>> you have your own "fork". When everyone has their own branch,
>> everyone is effectively equal. So yes you can expect much much
>> more forking. In Git land, forks are good. There's no way to
>> enforce that people only pull from some "official" source.
>>
>> It works out in practice so that 99% of the time people only care
>> about a couple branches of one repository. Counterintuitively, this
>> comes as a side- effect of git actually doing distribution properly
>> and making it easier for everybody's workflow. The overlay model by
>> contrast is quite broken on its own and virtually forces creation
>> of new overlays in order to make changes without the benifits of
>> version control (with regards to the rsync tree at least).
>>
>> What Github does is facilitate making it easy to fork/branch and
>> provide a central way to push changes back into a remote through
>> pull requests. Pull requests and other web services around git
>> hosting are pretty much the thing that makes github worth using.
>> From the standpoint of accepting patches, the differenc e to you is
>> rather than (or in addition to) accepting patches through bugzilla,
>> you can choose to accept a push directly from someone else's copy
>> of the repo. It isn't like a wiki - everybody commits to their own
>> repositories and pushing to a remote is on a whitelist basis just
>> like in centralized version control.
>
> This gets us into another topic altogether.
>
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.
>
> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.
>
> [1]
>
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html
>
> - - Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
> IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
> =MVyV
> -----END PGP SIGNATURE-----

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.