[Users] Meeting Minutes

[Bruno Coutinho Mundim]

Hi Frank and Roland,

thanks for your replies! Regarding the patching system proposed via
fork and pull requests it just seems to me more work than necessary,
specially to someone who is new to git. You would need to fork the
repository (and end up with a new URL as you pointed out), add this
new repo as a remote to your local clone, do the work there, push
it to the repo and request a pull to the official ET repo.
On the other hand, the alternative of creating a local branch,
do the work, diff between master and new branch and send it to
Trac seems more attractive. Anyways since you don't plan on
imposing either way or the other people at the end can choose what
works better for them.

Cheers,
Bruno.

On 03/31/2014 07:54 PM, Frank Loeffler wrote:
> 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
>