Re: Structuring configuration file versioning support in pkgsrc

[Keivan Motavalli <keivan%motavalli.me@localhost>]

On Tue, 22 May 2018 00:34:20 +0200
Joerg Sonnenberger <joerg%bec.de@localhost> wrote:

> 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

Yes, atomicity could become an issue later on, but if goals are to
change so broadly that support for remote configuration
repositories shouldn't be implemented (yet?), anything can be
rethought.

I haven't gone into details, but the consensus is that some changes
are to be made and starting with RCS seems like a good idea. After some
talking I learned that gsoc phases and deliverables are not as set in
stone as I thought and can be reworked now that there's some feedback.

Keivan