<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 11:36 AM, Jan Kundrát <span dir="ltr"><<a href="mailto:jkt@kde.org" target="_blank">jkt@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Personal clones are for forks. If you can't get a patch set accepted by<br>
"upstream", its equally unlikely that "upstream" are going to let you put a<br>
private branch in their repo for sharing that patch set.<br>
</blockquote>
<br></span>
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.<br>
<br></blockquote><br>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".<br><div><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm sure I'm not<br>
the only one carrying patches that are arguably sharable but not<br>
upstreamable.<br>
</blockquote>
<br></span>
Got an example so that I know what you're describing?<span class=""><br>
<br></span></blockquote><div><br></div>Well, to avoid any undesirable discussion, lets use something contrived instead of.. fraught.. as an example:<br></div><div class="gmail_quote"><br>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)<br><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br><br></div><div class="gmail_quote">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)<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've also used clones to share an experiment that may not belong in the<br>
proper repo now or ever. Making everyone who uses the main repo "pay" to<br>
carry an experimental branch is somewhat unfriendly, especially if you're<br>
not normally involved with the project. You may also wish to avoid the<br>
scrutiny of the others involved in the main project until you're ready,<br>
which the sudden appearance of a new branch during checkout would certainly<br>
invite.<br>
</blockquote>
<br></span>
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).<span class=""><br>
<br></span></blockquote><div><br></div><div>I wasn't there so I don't have any context for this.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As I see it, scratch repos are the first stage in a project's life cycle.<br>
Before playground, you might fiddle with something, drop it in a scratch<br>
repo and share the link on IRC. Deleting it is painless when you discover<br>
that your idea is terrible, or already exists elsewhere.<br>
</blockquote>
<br></span>
I agree with scratch repos being useful as a first step.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There are probably still quite a few people away for the holiday season,<br>
perhaps this decision can be deferred for a couple of weeks until its more<br>
likely that everyone is back and paying attention?<br>
</blockquote>
<br></span>
+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.<div class=""><div class="h5"><br>
<br>
With kind regards,<br>
Jan<br>
<br>
-- <br>
Trojitá, a fast Qt IMAP e-mail client -- <a href="http://trojita.flaska.net/" target="_blank">http://trojita.flaska.net/</a><br>
</div></div></blockquote></div><br></div></div>