Changes to our Git infrastructure

[argonel]

On Mon, Dec 29, 2014 at 11:36 AM, Jan Kundrát <jkt at kde.org> wrote:

> On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:
>
>> Personal clones are for forks. If you can't get a patch set accepted by
>> "upstream", its equally unlikely that "upstream" are going to let you put
>> a
>> private branch in their repo for sharing that patch set.
>>
>
> This is a social issue, then. What yuo describe makes sense -- if a patch
> is extremely dirty, for example, I can imagine a project maintainer not
> willing to "carry it" as a visible branch in their repo.
>
>
In one case, *I* am technically that maintainer. I have a personal clone
that has a very invasive patch set, that I rebase just about every time I
touch it. Once the design is entirely hammered out I'll share the changes,
but I think if it were a branch in the main repo it would be quite annoying
for others - and maybe for me if someone decided to "help". As a personal
clone I can disclaim liability for being annoying with the rebasing, and it
comes with a sense of privacy in that maybe I don't want any "help".

I also have a patch set that requires a forked KMessageWidget. (This was
from before it was moved to KWidgetsAddons). If I hadn't been the only
developer interested in experimenting with my changes to KMW, I could have
created a scratch repo for a lib containing only the modified KMW, and a
personal clone of Konversation that used it.

In KDE3 times, I had a fork of QTextEdit. Since we had qt-copy, I could
have used a personal clone to house that fork instead of importing it into
Konversation. I think I still could, since we have qt.git.

However, the personal prefixes appear to solve this problem semi-neatly. A
> perfect solution would be refs that aren't getting included in clones (and
> guess what, there's one review system which works exactly like that).
>
>  I'm sure I'm not
>> the only one carrying patches that are arguably sharable but not
>> upstreamable.
>>
>
> Got an example so that I know what you're describing?
>
>
Well, to avoid any undesirable discussion, lets use something contrived
instead of.. fraught.. as an example:

Konversation uses a treeview that acts exactly like a tab view. Which means
that when you scroll the treelist via the mouse scrollwheel, it moves the
selection instead of scrolling the list. "Upstream" disagrees with "mixing
the metaphors" and therefore has rejected my patch. (In truth, I didn't
feel strongly enough about the idea to even create a patch)

With enough activity around said personal clone, an argument to the
maintainer might be made for a configuration option, maybe even one that's
visible in the config dialog.

I have a couple of other UI patches of similar nature, that have bitrotted
since I moved to Fedora. In theory, had I shared them in personal clones,
someone else might have continued to keep the patches up to date.

In the first example above, in time those of us using the forked
KMessageWidget might have been able to finally win our case with the
KMessageWidget maintainer to cause my changes to be included. (In reality
though, my changes are probably useless and have never been shared except
as screenshots)

 I've also used clones to share an experiment that may not belong in the
>> proper repo now or ever. Making everyone who uses the main repo "pay" to
>> carry an experimental branch is somewhat unfriendly, especially if you're
>> not normally involved with the project. You may also wish to avoid the
>> scrutiny of the others involved in the main project until you're ready,
>> which the sudden appearance of a new branch during checkout would
>> certainly
>> invite.
>>
>
> That's a valid concern. On the other hand, it's a pretty simple way of
> "enforcing collaboration". There were keynotes during the last Akademy
> where people mentioned their worrying about development moving into
> isolated silos. Disabling clones leads directly to sort of an enforced
> collaboration (or, failing that, to people pushing stuff to GitHub).
>
>
I wasn't there so I don't have any context for this.

 As I see it, scratch repos are the first stage in a project's life cycle.
>> Before playground, you might fiddle with something, drop it in a scratch
>> repo and share the link on IRC. Deleting it is painless when you discover
>> that your idea is terrible, or already exists elsewhere.
>>
>
> I agree with scratch repos being useful as a first step.
>
>  There are probably still quite a few people away for the holiday season,
>> perhaps this decision can be deferred for a couple of weeks until its more
>> likely that everyone is back and paying attention?
>>
>
> +1, and sending a mail to kde-cvs-announce to make sure all KDE account
> holders are aware of both this and the other thread is a good idea.
>
>
> With kind regards,
> Jan
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141229/875a2982/attachment.htm>