[pydotorg-www] [Pydotorg] Mercurial mirror

anatoly techtonik techtonik at gmail.com
Sun Apr 18 09:42:23 CEST 2010


On Sat, Apr 17, 2010 at 2:12 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> The main idea is to allow people publish patch queues for review if
>> they do not have access to repository.
>
> That can be *easily* done with subversion also. PLEASE wait with such
> proposals until the actual need occurs: WHO wants to publish patches,
> and what patches specifically?

I have no idea how public patch queue management can *easily* be done
with Subversion. I am sure everybody out there would appreciate a
short proof-of-concept on how do you manage patches for projects for
which you do not have commit privileges. This will go straight into
community guide if we'll have one. Who knows - maybe after your
tutorial people will find the contribution process less cumbersome and
we will see a number of great patches popping up.

About WHO. I am, and those people who agree that maintenance of
various products that constitute Python services, their upgrade and
extension would be much better if we maintain those customizations as
series of patches to original upstream version. This is a way how
Debian, FreeBSD and other projects make packages compatible
independently of the upstream.

WHAT patches. First of all note that it is patch queue - one patch
depends on the other and they may even form directed acyclic graph
(DAG). Currently I want to see modifications to our Wiki in clear form
to be able to upgrade it and check that nothing is broken. I hope I am
not alone. There are issues with spam constantly creeping in in
hideous way, pages that can not be deleted, etc. Reread MoinMoin log
for all these years to compare which commits are missing is physically
impossible.

Patch queue can be applied to a newer version of MoinMoin and you can
see which patches are integrated upsteam, which fail and need to be
refreshed, so the process of upgrade will be much easier. People may
also maintain their *public* branches to *collaborate* on new
customizations and propose them once these customizations are
polished. Even if customization is not complete, everybody can pick up
patch queue from the state it was left and continue.

>> More than that - Mercurial can provide more than 70% of backend
>> functionality. It already allows importing patches, emailing them,
>> publishing patches in public repositories and sharing then between
>> repositories.
>
> Please drop it. The backend functionality is entirely elsewhere here:
> it's the web server delivering the pages. You are focused too much on
> technology, and too little on actual contribution. Please stop making
> requests for changes until you have ACTUALLY contributed something useful.

"Please wait", "please drop", "please stop", ... What is next? Martin,
I really value your efforts in maintaining python.org and contributing
to various pieces of software on backend. You are doing a lot of work,
but this doesn't mean you do not need help. For me managing all that
would require an enormous amount of time and knowledge. I can't see
how to follow development process with time constraints I have. I see
the solution in patch queues. You have other way, and I ask if you
don't mind sharing your way of doing things?

You are absolutely right when saying that I focused on technology or
tools to be exact. Proper tools save time and make routine and mundane
tasks as easy as playing solitaire, so even secretaries are addicted.
Right now nobody knows how to properly add new useful dynamic services
to python.org in maintainable, scalable and extensible way. I've
already said that static python.org website in 21 century is a shame,
some people took this too personal, but I won't change my opinion. I
won't apologize either, because I don't blame these people who
probably love this site too much.

What can I ACTUALLY contribute? I should ask you - how can I
contribute, and what should I do to actually contribute? To make it a
constructive discussion let's record your answers in Wiki FAQ for
potential contributors.

>> The fact that contribulyzer.py [3] is written in Python leads me to
>> rather philosophical question why contribulyzer.py was not (or could
>> not be) born in Python community?
>
> If you dislike this community too much, maybe you should look for a
> different one?

Oh, the missing "Please leave". =)

Philosophical context assumes a neutral position towards the fact
leaving people think about true reasons themselves.  Some may think
that people in Python Community are mostly developers, who are
overwhelmed with daily tasks, fixing things, reviewing patches,
triaging tracker issues, answering to emails of various OCD junkies
like me, and developers just do not have time to care about new or
potential contributors.  Some may think that all developers, who might
care and change things are already in ACKS, so they are already
satisfied with their proper attribution and do not feel motivated to
change things.

Your reaction is to protect the community you're comfortable with, so
you think that it is a good feature and we could do this. However, you
say that I dislike the community. That's WRONG. I dislike attitude of
some people, but to hate the community I need to exercise more in dark
side of the Force. That I really dislike is the fact that there is no
movement, and I am trying to change this by attracting more people,
discussing problems to create an environment to make contributions
easier and more fun. But if you'll directly ask me to shut up and go
away I'd probably couldn't resist. =)

-- 
anatoly t.


More information about the pydotorg-www mailing list