[akmods] Remove files from scm as now an archive is provided.

[Nicolas Chauvet]

2016-10-18 18:46 GMT+02:00 Sérgio Basto <sergio at serjux.com>:
> On Ter, 2016-10-18 at 09:45 -0500, Richard Shaw wrote:
>> On Tue, Oct 18, 2016 at 9:20 AM, Nicolas Chauvet <kwizart at gmail.com>
>> wrote:
>> > 2016-10-18 15:36 GMT+02:00 Richard Shaw <hobbes1069 at rpmfusion.org>:
>> > > commit bb01bb1e4d390e5d61a697fba30f12c556c42a9e
>> > > Author: Richard Shaw <hobbes1069 at gmail.com>
>> > > Date:   Tue Oct 18 08:36:45 2016 -0500
>> > >
>> > >     Remove files from scm as now an archive is provided.
>> > @Richard,
>> >
>> > Sorry, but I don't understand why you have forked akmods in your
>> > namespace that way.
>> > This is going to be more difficult to review the changes made.
>> >
>> Sergio and I thought it was a good idea as SCM != Upstream and to
>> give it a proper home. I don't see how it really makes anything more
>> difficult, the changes are in github.
>
> yes, I supported the idea, akmods should have a upstream source like
> others packages, kmodtool too , maybe we may put it in
> https://github.com/rpmfusion-infra
Well, you support the idea, but you still don't say why ?

To me this looks harder as we need to maintain ACL from the package
and from the "upstream" sources.
On large project, this seems appropriate, but on akmods/kmodtool are
are lighter, it's just hide things behind another step.

With the current layout, we can have the akmods project forked in
github from the package, and no worry if we are a rpms fork or the
"upstream" project.

We are also reducing the reviewer range by removing the commit log
from this project. Most people on this list might be more or less
interested in kmod anyway.

And for what is upstream concerned, I think the real upstream of
kmodtool/akmods should be "rpm" itself.

@Richard, so thx for having reverted the change and for taking care of
theses tools.



-- 
-

Nicolas (kwizart)