On Wed, 16 Mar 2016 15:39:40 +0100 James Pic <james...@gmail.com> wrote:
> On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu <maturb...@gmail.com> wrote: > > Even if I submit a patch I wouldn't be able to: > > - Merge it into mainline. > > - Upload the patched version to pypi. > > > > So it's a no-starter, > > I can't rely on my fork, not for production, as I > > should guarantee that the package it's, at least, as tested as mainline, > > which usually involves non-trivial infrastructure. > > If I understand correctly, you need a patch, but you don't want to do > it, because you can't have it released right away. > > Your work is to have a feature in a project, you want to use an app, > but you don't want to contribute to it. If I understand correctly, you > want volunteers to do the work for you so that you get your project > done and perhaps even get paid, and not give anything in return. > > Good patches are quickly merged. If it has tests, and good code > coverage, and supports new versions of Python, I can tell you it's not > going to take long before your patch is merged in most cases. > > Otherwise, yeah, just publish your fork on PyPi until it's merged > upstream. I don't see what's the problem here. We've had the case in > django-cities-light were a user implemented Region support, published > it in django-cities-reducedfat or something (lol), and then > contributed upstream, and then we released the contribution in > django-cities-light. What's the issue here ? > > >> > >> I know the first portings are hard but once you've ported a dozen it > >> becomes piece of cake so don't be afraid of trying ! And please contribute > >> to the apps !! > >> > >> I know some people who only open issues and never submit a patch on > >> github, isn't that super annoying? > > > > Really? you go around asking users to do the work of maintainers? > > I don't understand, what do you mean work ? Are you paying the > maintainers to maintain their projects ? Are you talking about > dual-licensed projects like django-suit where you payed an Enterprise > license for ? > > Well what do you prefer, that maintainers shut down a project because > they don't have time or motivation to keep on, or do you prefer that > the project lives on with community support ? > > If I understand your logic correctly, you should re-implement the > features you were using from an app in your own project to drop the > dependency on the app that you consider un-maintained. Either way, you > end up doing your job, but if you contribute then it's for everybody, > not just your project. > > Seems like "Open Source" doesn't wrok the same in your world and in mine :) > > Perhaps if you were maintaining Open Source apps you'd understand. I > don't know if you use any things like torrents, but do you know what > the "leecher" concept is like ? It's when a user downloads and then > doesn't share. > > I don't think I have anything to add here, I'm sure more experienced > hackers will find better phrasings than me for this. I may sound > harsh, but really I'm not, I'm just trying to understand how your > logic works and so far it seems broken for me so I'd really like to > understand. > > Also, about django-endless-pagination, I tried it once, but then > decided to go on with my own 5 sloc of JS implemantion of endless > pagination, using Django's normal pagination on the python side, so > I'd like to be convinced that it's really necessary in a project ! But > that I guess is another topic. > > Best ;) > > James > Hello there, I am not sure the tone of that discussion is suitable for that mailing-list ;) Regarding the initial discussion, if I understand correctly, the idea would be to find a way to prevent useful packages from turning into abandoned, unmaintained projects. >From my (personal) experience: - If someone is interested in taking over maintenance of an abandoned project, the original author is often quite happy to help - If the task seems too daunting to handle it single-handedly, you could try to find a few other power-users of the package who would be willing to help maintain it In that second case, the benefit of a generic/umbrella organisation would be to simplify the task of finding co-maintainers for a project. I am not part of the Django team, but I don't see why the maintenance of those extra projects would have to be handled by the Django team; a better start might be to approach the maintainers of a few projects that matter to you and discuss the idea with them; if that works, you could, as a group, decide whether you want that to happen within the Django org or within a different org. -- Raphaël -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20160316160632.3ae99db4%40ithor.polyconseil.fr. For more options, visit https://groups.google.com/d/optout.
