Re: CVS commit: pkgsrc/mk/pkgformat/pkg

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2015-02-03 at 01:08 GMT, OBATA Akio wrote:

> I have no idea how to determine what kind of commits must be proposed/discussed.
> Because I believe that adding "unlink" to tools is very much trivial change than
> reverted commits and such changes was just overlooked.

Whilst I don't want us to be tied down by draconian rules, my general
approach is:

 - If the change is a simple fix, no need for review.

 - If it's new functionality in mk/ or removal of existing
   infrastructure, ask for review on tech-pkg@.

 - If it's new functionality in a non-mk subsystem (e.g. ruby), ask
   for review from the language maintainer (e.g. taca) or someone who
   has a lot of experience in that area.  If in doubt, tech-pkg@.

That should cover 99.9% of cases.

> I wonder I should change my strategy. from "rely on pkgsrc main
> tree, and commit my minimal required infrastructure changes on it"
> to "fork the whole tree, pull required changes in my tree".
> I'm looking for the preferred infrastructure to do such job now.

We find GitHub very useful for this.  At Joyent we have substantial
patches to pkgsrc that aren't ready for integrating yet (and perhaps
won't ever will):

  $ git diff --shortstat pkgsrc_2014Q4..joyent/feature/miscfix/2014Q4
   264 files changed, 7263 insertions(+), 321 deletions(-)

  $ git diff --shortstat pkgsrc_2014Q4..joyent/feature/multiarch/2014Q4
   573 files changed, 3934 insertions(+), 986 deletions(-)

  $ git diff --shortstat pkgsrc_2014Q4..joyent/feature/pbulkmulti/2014Q4
   25 files changed, 140 insertions(+), 112 deletions(-)

It's a great way to test larger changes, ensure they work, and then
later integrate them when they've been baked a bit.

We also have a way to bulk build a pushed tree, so if you ever have
any changes you are unsure of, we are very happy to push them through
for you in that test environment and send you the results.

However, the vast majority of our changes still go directly upstream
by following the rules I set out above, as generally we want everyone
to benefit from our work, and also avoid having to deal with extra
merge conflicts.

I don't know if that's helpful - let me know if anything is unclear.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com