[Python-Dev] Submitting changes through Mercurial
skip at pobox.com
skip at pobox.com
Wed Mar 23 04:25:56 CET 2011
Senthil> You will have to 'push' your changes to those so that they are
Senthil> publicly visible and then point that url in the bug-tracker.
>>
>> I can see this turning into a giant bowl of spaghetti. How in the
>> world are people supposed to understand how all these repositories
>> are related to each other?
Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
Martin> whole point of "Distributed" version control systems.
No, you don't understand. Just the repositories I will have to deal with
will turn into a big bowl of spaghetti. I could care less about everything
else.
>> The Roundup interface is getting extraordinarily messy.
Martin> So what is your constructive proposal?
I don't know how constructive you will find it without a patch, but here is
a short brain dump.
In general, the display should be weighted more heavily with content most
relevant to the current stage of the issue. Elide or condense the other
stuff. I know nothing about modern day website development, but I imagine
someone who does could work some JavaScript magic without a lot of trouble.
For example:
* As soon as a case is "active" (left as an exercise for the reader to
determine) most of the content I find useful occurs below the fold
(attached files, review links, recent messages).
* As soon as a case is opened, maybe after initial triage (do we need a
new stage, "triage complete"?) by a core developer, it seems unlikely
that most of the elements of the classification section will change.
That can probably be a collapsed, and available to expose with a
little expander button for interested parties.
* I suspect parts of the process section can get a similar treatment
(status, dependencies, etc). Adding to the nosy list or subtracting
from it (need a new [-] button) should always be visible). I don't
find the limited width text field all that useful.
* Maybe the Files section should migrate to the top of the page once it
starts accumulating contents (or maybe when the stage is "patch
review"). Again, collapse the display so only the most recent patches
are visible seems reasonable to me.
* I don't know if it's possible to do easily, but when uploading a new
version of a patch the user could be prompted to select other patches
(or maybe they could be selected based on having the same name?)
which the new patch makes obsolete so they can be elided from the
default display.
Skip
More information about the Python-Dev
mailing list