[Users] Meeting Minutes

[Frank Loeffler]

On Mon, Mar 31, 2014 at 07:35:59PM +0200, Bruno Coutinho Mundim wrote:
> Is there a list for these thorns under heavy development?

I don't think there will be a list of "heavy development" thorns. The
intention here was more on "because it benefits those most". It would
apply to all thorns, assuming good judgement of the authors. A patch to
the flesh that could disrupt everyone's work should probably still get a
review for example.

> It would be
> useful to make this policy clearer, but it is interesting this soften
> requirements.

Outside of a release-window I that everyone with write access has
enough discipline and good judgement to make the best decision, at least
most of the time - and for the "other times" we have svn/git.

The main problem I see (and not just me) is that the current strict policy
is discouraging development.

> What about patches to thorns that nobody else seems to care besides the
> patch author?

As long as this doesn't break anything for somebody else, or makes the
code harder to read/maintain, I don't see a reason against this. In
other cases it might make sense to discuss this.

> Was there any change of policy? It is common to see
> patches on Trac sometimes for weeks or months just waiting for being
> reviewed.

Sadly - yes.

> People are just too busy or sometimes they just don't care for
> that particular patch. In those cases where a patch doesn't attract any 
> discussion on Trac, shouldn't it just be applied after a week or so of
> silence?

I would think we are all mature enough to judge about that in each
particular case. If you think that a particular patch should be tested
before you commit it, then ping everyone again after a while - if
necessary at the phone call, or (not preferred) by personal email.

> > * restrict commits just before release
> > * when using git, no longer propose patches but instead use pull requests
> That forces everyone with a patch to offer to have an account on
> bitbucket (or github), no?

We would still accept patches via trac of course, we would just ask to
provide patches via git if the author is able and willing to do that.

> Besides how do you envision the support for
> forked repositories in GetComponents?

Forked repositories have a distinct URL, different from the origin. I
don't think we need extra support for it - it should already work. As
for testing pull requests: I don't think people would use GetComponents
to switch between forks, but rather whatever tool the developer is
comfortable with - quite likely a special git utility.

Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140331/89fd8f74/attachment.bin