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
signature.asc
Description: Digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
