Re: [proaudio] Git migration

[Keen Blade <keenblade@xxxxxxxxx>]

I admit I haven't used any ebuilds from the proaudio-dev tree. As Dominique pointed out that tree is old stuff. I believe we can safely purge the tree. In case of someone needed something from there, we can put it as masked in our bleoved overlay.

On Mon, Jul 29, 2013 at 8:37 PM, Karl Lindén <spray.sucks@xxxxxxxxx> wrote:

2013/7/29 Keen Blade <keenblade@xxxxxxxxx>:

> I like git more than svn. I have no objection to migrate. They are both very
> nice to work with. Svn served great till now, and I still I have no
> complain.
> Dominique, I liked your idea: "we can purge all of them at the exception of
> 1 or 2 examples to show the file hierarchy".
> Or we can purge all of them and use overlay masks for the experimental
> stuff.
>
>

Well, I have not any objection against a migration either. For the
mask idea see below.

> On Mon, Jul 29, 2013 at 7:48 PM, Dominique Michel
> <dominique.michel@xxxxxxxxx> wrote:
>>
>> Le Mon, 29 Jul 2013 18:38:20 +0200,
>> Dominique Michel <dominique.michel@xxxxxxxxx> a écrit :
>>
>> > Le Sun, 28 Jul 2013 22:06:14 +0200,
>> > Karl Lindén <spray.sucks@xxxxxxxxx> a écrit :
>> >
>> > > Hi all!
>> > >
>> > > Some time ago there was some discussion about whether the proaudio
>> > > overlay should migrate to git. Would it make sense to do such a
>> > > migration or would it be too much work for now?
>> > >
>> > > What are the arguments that support such a change? Furthermore, what
>> > > are the arguments against?
>> > >
>> > > One supportive argument is that pull requests or equivalent are
>> > > pretty nifty. On the contrary, SVN is (in my opinion) pretty nice
>> > > to work with, but that is not a strictly technical argument.
>> >
>> > I use both svn and git, and for a so simple project, the only
>> > "advantage" I can see with git is it is never. Which is not a
>> > technical argument either. We can now argue about the never, the
>> > better.
>> >
>> > And well, I use a test overlay for my personal ebuilds and to work on
>> > the pro-audio ebuilds. If I have 2 ebuilds with the same name, emerge
>> > will use the one in my test overlay, and I see no simpler way to do
>> > the same with a private git branch.
>> >
>> > Also, my test overlay include things that have nothing to do with the
>> > pro-audio overlay, so it is no point for me to include it in some
>> > private git branch.
>> >
>> > So well, I have no use for git with pro-audio, and I am just fine with
>> > svn.
>>
>> But if someone can show he/she have an use case for a git repository in
>> the context of the overlay, I will have no objection to migrate.
>>

I agree.

>> >
>> > Also, the proaudio-dev branch can be used to put experimental or
>> > broken ebuilds, so that every body can look at them. For now, it is
>> > old stuffs in it, a real mess with no ChangeLog associated with the
>> > ebuilds, but nobody stop anyone to use it. It would be best to put
>> > ChangeLog files with new ebuilds here, with comments to explain what
>> > the issue is.
>> >
>> > Know someone what the ebuilds in proaudio-dev are? and if yes, can
>> > ChangeLog files be added. If not, we can purge all of them at the
>> > exception of 1 or 2 examples to show the file hierarchy. Or purge all
>> > of them and add a README.
>> >

I'm pro-purge, but as keenblade suggested we can choose to use
package.mask for experimental ebuilds. I support the package.mask
idea, mainly because it is what the way it is done in the main tree.
Anyway, even if we agree to use the package.mask I feel that the
proaudio-dev tree can be purged right away.

Regards,
Karl

>> > Dominique
>> >
>> > >
>> > > Thanks for your thoughts!
>> > >
>> > > Regards,
>> > > Karl
>> > >
>> > >
>> >
>> >
>>
>>
>> --
>> "We have the heroes we deserve."
>>
>>
>
>
>
> --
> Anyway it's all the same at the end...

--
Anyway it's all the same at the end...