Re: Structuring configuration file versioning support in pkgsrc

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, May 20, 2018 at 06:09:01AM +0200, Keivan Motavalli wrote:
> On Fri, 18 May 2018 14:05:10 +0200
> Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> 
> > I think you have a long way to go before you should start worrying
> > about that.
> 
> I do worry because further features depend on the solution being
> appropriately structured from the beginning, and a clear requirement for
> on the wiki for the proposed idea was to have the code be capable of
> working with multiple versioning systems, local and remote. 

Keep your code in a modular structure and adding support for other VCS
tools becomes a refactoring exercise. Personally, interaction with a
remote VCS sounds like an attempt to reinvent Ansible/Puppet and friends
badly and I would prefer to avoid going that way. But that's beside the
topic. In terms of abstraction, the RCS model simplifies some things as
operates naturally on individual files, but that shouldn't create major
hassles later. The biggest change is likely the question of atomicity
and I would punt on that for now.

> > Really, start with just RCS. It works very well for the
> > purpose at hand. In many ways, better than any other option. It is
> > also already used in NetBSD for a very similar purpose by the daily
> > jobs to backup some core configuration files.
> > 
> > I.e. a good first milestone would be to extend the current
> > CONF_FILES_* logic to checkout the last version from above RCS
> > database, compare it to the newly installed reference file
> 
> I'd like to produce code which is seen as useful to the project and
> unproblematic. This, however, is somewhat different from the proposal I
> submitted for review to tech-pkg
> (http://mail-index.netbsd.org/tech-pkg/2018/03/22/msg019543.htm,
> https://www.scribd.com/document/374557117/GSOC-2018-public-proposal-conf-versioning-in-pkgsrc?secret_password=eEZwOcGIyoie156VXgko)
> before the final document got approved.

Sure. I'm not your mentor, so I can only provide feedback for further
discussions. Take it with a pinch of salt ;-)

> If the proposal, in scope, technical implementation and milestones is
> to be changed so that it can better align with pkgsrc goals I'm fine
> with it: please just have the NetBSD Foundation tell me this is
> the path going forward and the way it should change.

Neither the milestones nor the implementation details are set in stone.
One of the important parts of the Summer of Code is dealing with the
real life challenges of software projects. Late feedback and the
resulting push backs is a common part of that and can be quite daunting,
so let's try to keep it at the start of the coding phase. Again, changes
that alter the nature of the project and its timeline are best discussed
with your mentors. They are the ones that will ultimately decide on pass
or fail, but such changes should also be consentious.

Joerg