[bug#40764] New package: r-restrserve

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On Thu, Dec 10, 2020 at 02:18:27PM +0100, Ricardo Wurmus wrote:
> 
> zimoun <zimon.toutoune@gmail.com> writes:
> 
> > Hi Chris,
> >
> > On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail@cbaines.net> wrote:
> >
> >> In the future, I'd strongly recommend not adding packages to the bottom
> >> of modules, unless you really want the package definition to be
> >> there. If every new definition gets added at the bottom, merge conflicts
> >> become very likely. Related to this, I also moved the package definition
> >> up off the bottom of the module.
> >
> > What do you mean?  From my understanding, we always add new R packages
> > at the botton of the files cran.scm or bioconductor.scm; mainly.
> 
> The problem is 100% with tooling.  Git needs some context to apply
> patches.  When you add package definitions to the bottom and that bottom
> context keeps changing you will always need to tell Git how to apply that
> patch.
> 
> By picking an arbitrary location somewhere in the file you avoid this
> problem because it’s unlikely that other people will pick that very same
> location.
> 
> > The only fix to avoid boring conflicts is to reduce the time between the
> > submission and the merge, IMHO.
> 
> Not even that would be a fix, because you can have two different people
> submitting patches for modifications at the bottom of the file at the
> same time.  Applying them one after the other will result in the same
> problem, no matter how fast we are.
> 
> Of course it’s always better to reduce time between submission and
> application.
> 
> It would be *great* if we could find another way to appease git and do
> the right thing for the most common case of simply adding a package
> definition to the bottom of the file, no matter what context there might
> be right above.
> 

This is why I like sorting them alphabetically :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]