Hi joola,
Here I ask, do I understand you correctly?
For clarity, I think you’re asking that:
I should use my (long existing) git-hub account and do a pull request and then put my changes there and then ask for them to be accepted?
Patches are, well… nothing I want to do. But read on, please.
Note that for what I have done already, “just for me” goes WAY beyond just what I need to do. And what I want to do for the community bears extraordinarily little relationship to contributions in Python or Postgres as contemplated in the materials you pointed me to - I read all of them.
My work already is in support of C4 section 1 points 1 and 4, which state:
- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
The scale and diversity are improved by having more diverse distributions and versions.
- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
When it comes to the installation, the problem is that the original installation script has no such provisions, presuming that “the natural life cycle” is interested in expanding the project beyond two versions of two distributions of Linux. And even if it was just limited to debian and ubuntu, the existing installation script is not really contemplating the future in a mature way.
A likely reason is that coders nearly universally ignore installation issues, as a recent dialogue I had with one Bil Auger on the Media Goblin developer’s list illustrated. … I’m not trying to be argumentative, I’m just trying to say that as a senior guy in our industry I know about this stuff intimately and have already got something that the current folks can likely run with and be more successful with. (My latest version is a substantial improvement over what I posted already - which was preliminary - and I need to do a bit more to complete the job.)
It’s worth pointing out that these changes are such a major reorganization and change to the installation script that it is simply ridiculous - ahem - inefficient to an extreme - to ask for several hundred patches (as outlined in the documents you pointed me at) when a simple replacement of the file (it’s just one file), tested by others on all platforms to ensure it works, is a vastly more efficient way to go. And that, by the way, is goal C4 section 1 point 3 - I can quote if you want!
Further, my work - that I’ve already done - restructures the former work so that it will be easy to add not just new releases but new platforms, especially those that use Redhat Package Manager - and that’s a LOT of systems.
Further, there’s a VERY good argument to be made - that I’m not really making here - that the use of release names is a big mistake, and that code should be changed to just use it to make humans happy in display but not use it in making decisions about what the code should do because it’s not fine-enough grained. But that’s not really my concern - I don’t have time for that. But the folks who wrote it in the past should reconsider, in my view.
It’s a LOT more work for me to do what I believe you proposed than if I’m just given the audience to talk with and can share what I’ve done and leave it to them.
But, it’s really up to you folks.