| 1 |
Dnia 6 sierpnia 2016 23:12:55 CEST, Peter Stuge <peter@×××××.se> napisał(a): |
| 2 |
>Peter Stuge wrote: |
| 3 |
>> How can I help improve ..? |
| 4 |
> |
| 5 |
>Michał Górny wrote: |
| 6 |
>> people focused on preaching and/or implementing random crap-based |
| 7 |
>> solutions without even stopping for a few minutes to consider what |
| 8 |
>> we exactly need. |
| 9 |
> |
| 10 |
>You could interpret my question as "what exactly do we need" ? |
| 11 |
|
| 12 |
If you really want to know... |
| 13 |
|
| 14 |
For a start, something that would satisfy the performance, maintainability and security needs of infra. I haven't heard of anything like that, so you'll probably have to start a new project. I suggest high quality C/C++ since other languages are either completely unreliable, slow and/or designed to be a security nightmare. |
| 15 |
|
| 16 |
Once again, bear performance in mind. Most of the existing tools can't handle big repos. It ain't productive when every small action takes 5 seconds. |
| 17 |
|
| 18 |
Accessibility is also important, but without hurting convenience. Probably accessible web interface with optional ES booster and a reasonably stable API (i.e. not pybugz-style 'XMLRPC is not cool anymore, so we instantly kill all the API you ever used'). |
| 19 |
|
| 20 |
That's it for the generic requirements. Now for the specific workflow: |
| 21 |
|
| 22 |
1. Preferably no custom registration. Some kind of SSO via Bugzilla, OpenID or GitHub would work. No additional passwords, thank you. |
| 23 |
|
| 24 |
2. Ability to conveniently post branches for review. Git push is most preferable, but I guess we can live with mails if done sanely). |
| 25 |
|
| 26 |
3. Ability to conveniently get branches for merging. Again, git pull is the best option here. No 'click and download this dozen patches'. |
| 27 |
|
| 28 |
4. No need for remote merge. The thing's not going to push anything directly to git.g.o. |
| 29 |
|
| 30 |
5. Fast review with per-line and general comments. Ability to hide threads as resolved. Lightweight so that people don't have to put multiple remarks in a single comments. Readable so it's easy to note remarks made by others. |
| 31 |
|
| 32 |
6. Good support for updating commits. Preferably being able to reapply (move) comments as appropriate. |
| 33 |
|
| 34 |
7. Some kind of nice assignment/CC system with notifications that covers all developers without explicit signup. |
| 35 |
|
| 36 |
>> GitHub works for us. GitHub works for our contributors. GitHub |
| 37 |
>> boosts our productivity, unlike those vain discussions. |
| 38 |
> |
| 39 |
>Windows works for me. Windows works for my customers. Windows |
| 40 |
>boosts my business, unlike vain discussions about open source |
| 41 |
>and free software. ;) Maybe you get my point? |
| 42 |
|
| 43 |
Does Microsoft let you use Windows for free? But yes, I generally agree. I regularly use Windows to print after many hours wasted on trying to get printing working on Linux. Having to print three pages a month, my business is much happier with it. |
| 44 |
|
| 45 |
> |
| 46 |
> |
| 47 |
>> We don't have time for all this tin foil hat nonsense. |
| 48 |
> |
| 49 |
>I think we have all the time in the world, and I think it's important |
| 50 |
>for us to innovate also in this field if neccessary, as we have and |
| 51 |
>continue to do in other distro-development-related fields. |
| 52 |
|
| 53 |
Sure we do. In the meantime, nobody uses gentoo anymore because it still can't deal with accepting contributions and in the meantime the few last developers retired, and users long ago switched to the comparatively recent distribution of Debian stable. |
| 54 |
|
| 55 |
|
| 56 |
-- |
| 57 |
Best regards, |
| 58 |
Michał Górny (by phone) |
Archives