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

2016-10-18 18:46 GMT+02:00 Sérgio Basto <sergio(a)serjux.com&gt;: > > On Ter, 2016-10-18 at 09:45 -0500, Richard Shaw wrote: > > > > On Tue, Oct 18, 2016 at 9:20 AM, Nicolas Chauvet <kwizart(a)gmail.c > > om> > > wrote: > > > > > > 2016-10-18 15:36 GMT+02:00 Richard Shaw <hobbes1069(a)rpmfusion.o > > > rg>: > > > > > > > > commit bb01bb1e4d390e5d61a697fba30f12c556c42a9e > > > > Author: Richard Shaw <hobbes1069(a)gmail.com&gt; > > > > 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.