Re: [Telepathy] Telepathy 1.0 and moving to Github

[Gergely Polonkai]

Hello,

what came to my mind after a good night’s sleep is git-series[1]. It
resembles the BZ/Gerrit workflows in that it keeps track of the evolution
of a patch series. See the project’s README for more info.

I wouldn’t say, though, that it should be a requirement for developers. I
know such iterations can hold vital information that can get lost in the
middle of a rebase, but depending on this feature would put extra burden on
anyone who wants to commit some typo changes. Also, it is not part of
vanilla Git (yet?) and installing it may not be straightforward on some
older machines.

Best,
Gergely

[1] https://github.com/git-series/git-series

On Tue, Nov 1, 2016, 18:34 Martin Klapetek  wrote:

Hey,

first of all, thanks George and Alex for pushing the work forward!

On Sun, Oct 30, 2016 at 12:59 PM, George Kiagiadakis 
wrote:

Hi all,



Moving to Github



This is some great news! I realize it's too late now so I'll merely mention
this perhaps for future reference, but there's also Gitlab, where for
example
the Accounts SSO project is hosted. Gitlab is more free-as-in-freedom
software
friendly and regularly releases open source version of their server. I feel
like
a free software project fits better with Gitlab rather than Github, but I
can also
see why Github is the obvious choice.

On the issue of Bugzilla vs Github for patches - well, Bugzilla is a tool
meant
for bugs, not really for patch reviews, especially with git workflows.
Github is
much much more better equipped for code reviews and accepting patches.

I mean reviews like https://bugs.freedesktop.org/show_bug.cgi?id=34416
require so much manual work, copy paste and context switching while forcing
the patch to be contained in narrow column (I have a 27" screen, I want to
use all
of my screen). I find this terrible for reviews compared to, say, Github
reviews,
which also allows to maintain clean comments threads (in addition to clean
commit
history).

I as a developer want to do as little work as possible when it comes to
posting
patches but also reviewing patches. I'm reading the diff, I want to say
something about
the line I'm reading right now, I click it, I write my thoughts, I press a
button, all done.
The bugzilla that's hosted on FDO is in no way "great system for patch
review", sorry.

I'd vote for having issues on Github too. It keeps the project together,
doesn't
require two very different accounts (Github and Bugzilla) to work on one
project
and finally, Github issues are integrated out-of-the-box with the Github
reviews.
Bugzilla as it stands doesn't really offer much over Github's issues, so
imo no
reason to not keep the project all under single roof. It should be where
the development
happens.

Wiki - as Gergely mentioned, Github pages may be a very good alternative.
From
there it could even link to individual project's wikis.

Cheers
-- 
Martin Klapetek | KDE Developer
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[George Barrett]

On Tue, Nov 01, 2016 at 12:03:44AM +0500, Alexandr Akulich wrote:
> I can not agree. You can fit a trivial change into an individual patch, but
> it would be more clear and easier to review a branch with an implementation
> of a new feature, rather than a single patch for that.
> It is better when you *can* propose a commits series, than when you're
> limited by a patch. (I would like to say "hello" to reviewboard here).

Well, no-one said anything about a /single/ patch either. As I'm sure you
know, Bugzilla has no issue with attaching a set of patches to a bug. Feature
branches that are justifiably more than a handful of patches are quite the
edge case, but git has support for this baked-in with git-bz anyway.

> There is no problem to rebase your own branch and clear it before merging.

Well, except for it being a pain. Requiring a branch-in-review to be based on
the upstream tip before merge sounds like it just adds an extra round-trip
between reviewer and contributor.

> We didn't said any word about pull request.

I'm afraid I don't understand how GitHub's issues system is applicable to code
contributions, then.

> Oh, indeed? Let's start with any random feature. Can BZ expand a diff to
> show you a ten more lines of code before the change?

No, but that's hardly "any random feature". I'm not trying to say that BZ's
features are a superset of GitHub's, because that just isn't true. Nor is it
the case that GitHub's features are a superset of BZ's.

> >  * There's no big "MERGE NOW" button to be tempted by mid-review (I'm
> >guilty of this)
>
> It is not a problem of github. You should be able to resist from clicking
> on buttons. :)

Perhaps, but I don't think code review UI should be steering a reviewer into
accepting code. You're probably right, though, the more I think about it the
more it seems like a non-issue; the Telepathy committers aren't me ;)

> >  * Poor commit messages are understood as valid grounds to reject a
> >patch
>
> It is equally a valid point to reject a commit.
>
> > * editing a patch is easier than rewriting branch history
>
> No. Rewriting a branch is easier, if you use a proper tool (git rebase
> --interactive; git add --patch at the very least).

I meant that in the context of rewriting commit messages: You can change the
commit message without leaving the browser, you just edit the text. I think
people would be much less frustrated over commit message nitpicking if
rebase-then-push weren't involved; even more so since such nitpicking is part
of established convention on BZs.

Something else you lose with branches over patches is patch history. I seem to
recall hunk comments being clobbered by force pushes.

> >  * There's no argument over git merge vs git rebase, over a commit log
> >full of merge commits or rewriting history
>
> In Telepathy we have a very reasonable merge/rebase convension for years.

Allow me to reword: There's no reason for someone to uselessly open a bug
linking a blogger's opinion on merge vs rebase ;)

> You're actually comparing a really bad github workflow vs an ideal BZ
> workflow.

My aim was more to compare the sort of workflow each tool seems to promote,
but it's true that I've never been exposed to discussion over the ideal GitHub
workflow. But it remains the case that I'm much more likely to submit code to
a BZ than to open a pull request on GitHub; I'm sure I'm not alone, but I
guess the question is whether I'm in the minority ;)
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hello George,

On Mon, Oct 31, 2016 at 11:18 PM, George Barrett  wrote:

> On Sun, Oct 30, 2016 at 06:59:07PM +0200, George Kiagiadakis wrote:
> > 1) Where should we keep tickets? Right now they are also split between
> > bugzilla and github. No decision has been made yet. Our options seem
> > to be bugzilla, github and phabricator.freedesktop.org.
> >
> > -> github: most user friendly, very limited
> > -> bugzilla: less user friendly, more options, some basic ones are not
> > available though (they require admin access...); currently cluttered
> > with old & dead stuff
> > -> phabricator: even less user friendly (imho), but the most powerful
> > one
>
> My vote would be for keeping that stuff on the FD.O Bugzilla. I would
> argue that Bugzilla has an edge over GitHub in that the BZ workflow
> promotes patch nit-picking and a clean commit history:
>
>  * Individual patches are submitted instead of pull requests for
>branches.
>
I can not agree. You can fit a trivial change into an individual patch, but
it would be more clear and easier to review a branch with an implementation
of a new feature, rather than a single patch for that.
It is better when you *can* propose a commits series, than when you're
limited by a patch. (I would like to say "hello" to reviewboard here).
There is no problem to comment any line of code in any commit of a branch.
There is no problem to rebase your own branch and clear it before merging.
We didn't said any word about pull request.


>  * BZ has a great system for patch review
>
Oh, indeed? Let's start with any random feature. Can BZ expand a diff to
show you a ten more lines of code before the change?


>  * Bug discussions and patches share the same thread
>
 * There's no big "MERGE NOW" button to be tempted by mid-review (I'm
>guilty of this)
>
It is not a problem of github. You should be able to resist from clicking
on buttons. :)

 * Poor commit messages are understood as valid grounds to reject a
>patch

It is equally a valid point to reject a commit.

> * editing a patch is easier than rewriting branch history
No. Rewriting a branch is easier, if you use a proper tool (git rebase
--interactive; git add --patch at the very least).

>  * There's no argument over git merge vs git rebase, over a commit log
>full of merge commits or rewriting history
>

In Telepathy we have a very reasonable merge/rebase convension for years.

You're actually comparing a really bad github workflow vs an ideal BZ
workflow.
In fact, you can


> Particularly with a project with as many components as Telepathy, I feel
> like GitHub issues would be a definite step backward.
>
> I'd also recommend BZ over Phabricator, but admittedly this opinion is
> not particularly well informed. My previous impressions of it has been
> that it's in desperate need of a man page, not a good quality in a
> website. I wouldn't be the only one who is more comfortable with BZ.
> That said, I have no idea what additional features it provides; it may
> well be worth it for Killer Feature X.
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[George Barrett]

On Sun, Oct 30, 2016 at 06:59:07PM +0200, George Kiagiadakis wrote:
> 1) Where should we keep tickets? Right now they are also split between
> bugzilla and github. No decision has been made yet. Our options seem
> to be bugzilla, github and phabricator.freedesktop.org.
>
> -> github: most user friendly, very limited
> -> bugzilla: less user friendly, more options, some basic ones are not
> available though (they require admin access...); currently cluttered
> with old & dead stuff
> -> phabricator: even less user friendly (imho), but the most powerful
> one

My vote would be for keeping that stuff on the FD.O Bugzilla. I would
argue that Bugzilla has an edge over GitHub in that the BZ workflow
promotes patch nit-picking and a clean commit history:

 * Individual patches are submitted instead of pull requests for
   branches.
 * BZ has a great system for patch review
 * Bug discussions and patches share the same thread
 * There's no big "MERGE NOW" button to be tempted by mid-review (I'm
   guilty of this)
 * Poor commit messages are understood as valid grounds to reject a
   patch, and editing a patch is easier than rewriting branch history
 * There's no argument over git merge vs git rebase, over a commit log
   full of merge commits or rewriting history

Particularly with a project with as many components as Telepathy, I feel
like GitHub issues would be a definite step backward.

I'd also recommend BZ over Phabricator, but admittedly this opinion is
not particularly well informed. My previous impressions of it has been
that it's in desperate need of a man page, not a good quality in a
website. I wouldn't be the only one who is more comfortable with BZ.
That said, I have no idea what additional features it provides; it may
well be worth it for Killer Feature X.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hi Daniel,

Our manpower is very limited, but IMO we need to polish the specification
and carefully test everything to make Tp 1.0 to be the best release, rather
than rush, declare release earlier and make the situation even worse.
Yet another point is Empathy. It was holding the 1.0 release back and now
it seems to be close to removed/abandoned. I don't think that Empathy with
Tp 1.0 support will be released in time for Debian.

On Mon, Oct 31, 2016 at 1:23 PM, Daniel Pocock  wrote:

>
>
> On 30/10/16 17:59, George Kiagiadakis wrote:
>
> > Therefore, the point is valid, so the new plan now is to finish
> > Telepathy 1.0 as soon as possible and then carry on with a clean spec
> > and codebase.
> >
>
> Has any target date been set for this?
>
> Is it intended to be part of the next Debian release?  If so, the freeze
> is coming soon, potentially 5 January 2017:
>
> https://wiki.debian.org/DebianStretch
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hello Gergely.

On Mon, Oct 31, 2016 at 11:46 AM, Gergely Polonkai 
wrote:

> You can upload custom files as releases, and you can even do it from CI
> systems like Travis. Yet, I think releases should stay at fdo (although the
> CI could generate that one, too).
>
Indeed. Thanks!

>
> On Sun, Oct 30, 2016, 23:31 George Kiagiadakis 
> wrote:
>
>> On 10/31/2016 12:15 AM, Alexandr Akulich wrote:
>> > Hi George,
>> >
>> > thank you for the summarize. I have no time for a verbose answer, but
>> > would like to make some note.
>> >
>> > We can not use "Github releases" feature, because:
>> > 1) We need to prepare release in some special way. Namely, we generate
>> > documentation for release tarballs. Github archives contains only the
>> > tree snapshot from a tagged commit.
>> > 2) The archive directory name is project name + tag name. For
>> > TelepathyQt we have archive "telepathy-qt-0.9.7.tar.gz" with directory
>> > "telepathy-qt-telepathy-qt-0.9.7".
>> >
>> > I think we should use https://telepathy.freedesktop.org/releases/ , but
>> > I didn't checked yet if we can place sources of new components
>> > (TpQt-based CMs) there (probably we can do it without help from admins).
>> >
>>
>> Yes, releases should and will happen like before. There is no need for
>> admin access, we all have write permissions there.
>> ___
>> telepathy mailing list
>> telepathy@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/telepathy
>>
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Daniel Pocock]

On 30/10/16 17:59, George Kiagiadakis wrote:

> Therefore, the point is valid, so the new plan now is to finish
> Telepathy 1.0 as soon as possible and then carry on with a clean spec
> and codebase.
>

Has any target date been set for this?

Is it intended to be part of the next Debian release?  If so, the freeze
is coming soon, potentially 5 January 2017:

https://wiki.debian.org/DebianStretch
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Gergely Polonkai]

You can upload custom files as releases, and you can even do it from CI
systems like Travis. Yet, I think releases should stay at fdo (although the
CI could generate that one, too).

On Sun, Oct 30, 2016, 23:31 George Kiagiadakis  wrote:

> On 10/31/2016 12:15 AM, Alexandr Akulich wrote:
> > Hi George,
> >
> > thank you for the summarize. I have no time for a verbose answer, but
> > would like to make some note.
> >
> > We can not use "Github releases" feature, because:
> > 1) We need to prepare release in some special way. Namely, we generate
> > documentation for release tarballs. Github archives contains only the
> > tree snapshot from a tagged commit.
> > 2) The archive directory name is project name + tag name. For
> > TelepathyQt we have archive "telepathy-qt-0.9.7.tar.gz" with directory
> > "telepathy-qt-telepathy-qt-0.9.7".
> >
> > I think we should use https://telepathy.freedesktop.org/releases/ , but
> > I didn't checked yet if we can place sources of new components
> > (TpQt-based CMs) there (probably we can do it without help from admins).
> >
>
> Yes, releases should and will happen like before. There is no need for
> admin access, we all have write permissions there.
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[George Kiagiadakis]

On 10/31/2016 12:15 AM, Alexandr Akulich wrote:
> Hi George,
> 
> thank you for the summarize. I have no time for a verbose answer, but
> would like to make some note.
> 
> We can not use "Github releases" feature, because:
> 1) We need to prepare release in some special way. Namely, we generate
> documentation for release tarballs. Github archives contains only the
> tree snapshot from a tagged commit.
> 2) The archive directory name is project name + tag name. For
> TelepathyQt we have archive "telepathy-qt-0.9.7.tar.gz" with directory
> "telepathy-qt-telepathy-qt-0.9.7".
> 
> I think we should use https://telepathy.freedesktop.org/releases/ , but
> I didn't checked yet if we can place sources of new components
> (TpQt-based CMs) there (probably we can do it without help from admins).
> 

Yes, releases should and will happen like before. There is no need for
admin access, we all have write permissions there.
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Alexandr Akulich]

Hi George,

thank you for the summarize. I have no time for a verbose answer, but would
like to make some note.

We can not use "Github releases" feature, because:
1) We need to prepare release in some special way. Namely, we generate
documentation for release tarballs. Github archives contains only the tree
snapshot from a tagged commit.
2) The archive directory name is project name + tag name. For TelepathyQt
we have archive "telepathy-qt-0.9.7.tar.gz" with directory
"telepathy-qt-telepathy-qt-0.9.7".

I think we should use https://telepathy.freedesktop.org/releases/ , but I
didn't checked yet if we can place sources of new components (TpQt-based
CMs) there (probably we can do it without help from admins).
___
telepathy mailing list
telepathy@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Telepathy 1.0 and moving to Github

[Gergely Polonkai]

Hello,

I more than welcome the new book; I wanted to create a CM for the Matrix
protocol, but I failed miserably due to lack of docs and tutorials.

Onthe wiki: how about moving to GitHub Pages? It is not a wiki per se, but
may be better on the long run: it resides in a Git repository, so it can be
object to code review.

Best,
Gergely

On Sun, Oct 30, 2016, 18:43 George Kiagiadakis  wrote:

> Hi all,
>
> There was a discussion on IRC on Friday about our short-term plans. I
> will summarize it here for the archive and for anyone else who is
> interested in project news.
>
> Telepathy 1.0
> =
>
> After some discussion with ramcq, Kaffeine suggested that we should
> proceed with releasing telepathy 1.0 before introducing new features, as
> it is easier at this point to merge the 'next' branches that were left
> aside a few years ago.
>
> We believe (but haven't fully checked) that all the components that we
> are interested in have nearly-finished 'next' branches around, including
> KDE-Telepathy, which is the most active client at the moment.
>
> Therefore, the point is valid, so the new plan now is to finish
> Telepathy 1.0 as soon as possible and then carry on with a clean spec
> and codebase.
>
> Moving to Github
> 
>
> Currently we, all the active contributors, work on Github clones of the
> telepathy repositories, since it makes the development process quite
> easier (among other reasons). Up to now, we used to have a "TelepathyQt"
> organization, which included a clone of tp-qt together with the main
> repositories of the Qt-based connection managers, while glib-based
> component repositories could also be found under my profile.
>
> As you can understand, this situation was a mess, so I proposed that we
> move the official upstream on a single Github organization. We all
> agreed, but we said to keep the freedesktop repositories as mirrors.
>
> Kaffeine therefore renamed the "TelepathyQt" organization to
> "TelepathyIM" ("Telepathy" was already taken) and I have already cloned
> there all the important repositories. The move is not complete though
> until we setup the mirrors properly (ideally, commits should be
> automatically pushed to fdo when we push to github). I will ask the
> admins to see what we can do about that.
>
> In any case, please ***consider https://github.com/TelepathyIM to be
> upstream from now on***
>
> Note, though, that not all repositories have been moved. I took this as
> an opportunity to cleanup the components and "save" only the parts that
> make sense.
>
> The following (dead) repositories still remain in fdo:
>
> - telepathy-python (dead; deprecated in favor of gobject-introspection)
> - telepathy-butterfly (dead; tp-python based cm for msn, enough said...)
> - telepathy-sunshine (dead; tp-python based cm)
> - telepathy-farsight (dead; called, telepathy-farstream now)
> - telepathy-origami (empty repository)
> - telepathy-qt-farstream (empty repository)
> - telepathy-qt4 (symbolic link to telepathy-qt)
> - telepathy-qt4-yell (dead; used to be a temp repo for Call1 stuff)
> - telepathy-yell (dead; same as telepathy-qt4-yell)
>
> And the following also remain in fdo, though they could be saved, but
> since our manpower is limited, I have kept them out for now (for less
> clutter):
>
> - telepathy-doc (needs a major cleanup; maybe not worth saving, I'm
> thinking about starting a new book based on its material)
> - telepathy-ring (the ofono CM - not really essential for the desktop
> use case; it hasn't been updated since 2011, lacks support for Call1 and
> has no 'next' branch... I'm not dealing with it, sorry)
> - telepathy-phoenix (non-essential stuff for now; maybe some day...)
> - telepathy-ssh-contact (also non-essential stuff for now)
>
> Regarding the development process on github, one difference with the
> previous situation is that we are allowed to push personal branches on
> the main repositories. In order to keep the branches list tidy, though,
> I would recommend prefixing the name of each personal branch with the
> username of the developer working on it, so for example a branch can be
> called 'gkiagia/myfixes' instead of 'myfixes'. The second difference is
> that we can have reviews directly on the commits, plus review requests.
>
> Misc
> 
>
> Other topics that were brought up after the github move topic were:
>
> 1) Where should we keep tickets? Right now they are also split between
> bugzilla and github. No decision has been made yet. Our options seem to
> be bugzilla, github and phabricator.freedesktop.org.
>
> -> github: most user friendly, very limited
> -> bugzilla: less user friendly, more options, some basic ones are not
> available though (they require admin access...); currently cluttered
> with old & dead stuff
> -> phabricator: even less user friendly (imho), but the most powerful one
>
> 2) What about a wiki? The current tp wiki is abandoned and the problem
> with it is that you need a