On Fri, Oct 27, 2017 at 2:44 PM, Kurtis Rader <kra...@skepticism.us> wrote:
> On Fri, Oct 27, 2017 at 2:24 AM, Siteshwar Vashisht <svashi...@redhat.com> > wrote: >> >> We are currently discussing the state of branches on GitHub[1]. I am >> thinking about : >> >> * Merging beta branch into master and do the development in master. >> * Remove both alpha and beta branches. Commits from alpha and beta >> branches can be tagged with respective git tags if required. >> > > +1 to moving development from the "beta" to "master" branch as that seems > to be the most common git development model. And dropping both the "alpha" > and "beta" branch as they confuse people (e.g., me) and aren't needed at > this time given the current pace of development. We can always create > release specific branches or tags when that is needed. > It's been a week and no one has commented on this proposal other than myself. Nor has there been any feedback on the Github issues and PRs where this proposal has been brought up. The key question isn't what SCM branches (e.g., `beta`) should be more or less permanent fixtures of the project. The key question is whether everything required to build ksh93 should be split out from all the other AST code. Which would effectively ghettoize the non ksh93 code. Personally, I am only interested in ksh93. Not any of the other AST commands. I have no interest in maintaining AST commands like `pax` since every UNIX based OS provides a usable implementation that is being maintained by others. I suspect my viewpoint is representative of the majority of people. Given that https://github.com/att/ast/ is meant to represent all the AST code a reasonable compromise may be to keep the `master` branch representative of the entire code base and create a `ksh` branch that eliminates all code not needed to build and test ksh. On the other hand it may be better for the future of ksh if an `ast` branch that includes everything is created and the `master` branch is stripped down to the ksh code. Another option is to fork AST and in that fork strip out everything not needed by the ksh program. Please note that I do recognize there are people interested in the AST code base as a whole. Most notably the Nmake build tools. The question is how best to keep those people happy while maximizing the likelihood that ksh will be a relevant, vibrant, shell in the future. Let the flame wars begin :-) -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank
_______________________________________________ ast-developers mailing list ast-developers@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-developers
