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
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
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
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
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
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.
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?
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
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
>
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
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
11 matches
Mail list logo