Cool, thanks :-)
Ursprüngliche Nachricht
Von: Lukas Tribus
Gesendet: 18. Jänner 2019 14:14:06 MEZ
An: Aleksandar Lazic
CC: haproxy , Willy Tarreau , "Tim
Düsterhus"
Betreff: Re: haproxy issue tracker discussion
Hello Aleksandar,
On Fri, 18 Jan 2019 at 12:54,
Hello Aleksandar,
On Fri, 18 Jan 2019 at 12:54, Aleksandar Lazic wrote:
>
> Hi.
>
> As there are now the github templates in the repo can / should we start to
> create issues & features on github?
Yes, you can go ahead and start filing bugs and features.
There's some minor tweaking yet to
y
Betreff: Re: haproxy issue tracker discussion
On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote:
> May I suggest the following to move forward?
(...)
> That way we can test the process with a small, unimportant, test issue.
> The automated closing based on the labels can t
On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote:
> May I suggest the following to move forward?
(...)
> That way we can test the process with a small, unimportant, test issue.
> The automated closing based on the labels can than be added a few days
> later. I don't expect huge
Willy,
Lukas,
Am 14.01.19 um 02:08 schrieb Lukas Tribus:
> My simple github script which relays the PR to the mailing list uses
> the GH Rest API through the agithub client [1]. I will have a look at
> how extensible it is, but extracting labels of closed issues and
> reopening it if it contains
Hello,
On Sat, 12 Jan 2019 at 13:38, Willy Tarreau wrote:
> > The situation on GitHub does not need to mirror the situation on
> > haproxy.org. You could still use separated repositories on haproxy.org
> > to separate permissions and push the "validated" commits to GitHub. This
> > is what the
On Sat, Jan 12, 2019 at 01:09:08PM +0100, Tim Düsterhus wrote:
> Willy,
>
> Am 12.01.19 um 12:45 schrieb Willy Tarreau:
> >> This example makes me wonder, though: Should the various branches be
> >> separate repositories on GitHub like on haproxy.org or should they be
> >> actual branches (e.g.
Willy,
Am 12.01.19 um 12:45 schrieb Willy Tarreau:
>> This example makes me wonder, though: Should the various branches be
>> separate repositories on GitHub like on haproxy.org or should they be
>> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
>> haproxy/haproxy-1.8) for the mirror?
Hi Tim,
On Sat, Jan 12, 2019 at 12:24:23PM +0100, Tim Düsterhus wrote:
> > This one is less of a problem because the likelihood that someone writes
> > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
> > they do it on purpose to annoy us of course.
>
> It would only
Willy,
Am 12.01.19 um 08:47 schrieb Willy Tarreau:
>> The following issue was closed ... :
>> https://github.com/lukastribus/hap-issue-trial/issues/3
>>
>> from another repository, just because I referenced the issue
>> prepending the word "Fix":
>>
Lukas,
Am 12.01.19 um 02:53 schrieb Lukas Tribus:
> As our intention I believe is to keep the issue open until all
> affected branches are fixed, this github feature is a little
> inconvenient. But I guess we can just refer to the issue by prepending
> it with "issue" or "bug", so GH doesn't see
Hi Lukas,
On Sat, Jan 12, 2019 at 02:53:45AM +0100, Lukas Tribus wrote:
> Hi Tim, Willy,
>
> apologies for not responding sooner, I always have to force myself to
> policy/organizational discussions, when I can also read stack or
> straces :)
You really don't need to apologize :-)
> > So in
Hi Tim, Willy,
apologies for not responding sooner, I always have to force myself to
policy/organizational discussions, when I can also read stack or
straces :)
>> When should the binary "issue open" / "issue closed" property be
>> toggled? When the issue is fixed in Dev? When the issue is
Willy,
Am 10.01.19 um 19:40 schrieb Willy Tarreau:
> Conclusion : the affected status is only temporary and enough to go
> once the backport is done. This simply means we don't need a "fixed-1.9"
> or whatever, we just have to remove the "affected" label exactly as it
> would have been if the
Hi Tim,
On Thu, Jan 10, 2019 at 04:12:54PM +0100, Tim Düsterhus wrote:
> > I tend to think that if labels already mark the relevance to a branch,
> > then they override the status and probably we don't really care about
> > the status. The "moby" project above does that by the way, with
> >
Aleks,
Am 10.01.19 um 15:30 schrieb Aleksandar Lazic:
> In general I also see a huge benefit to add a issue tracker I also know
> that's a
> workflow change for the developers.
>
> As I also follow the discussion let suggest me the following.
>
> * add some templates for the different cases e.
Willy,
Am 09.01.19 um 15:22 schrieb Willy Tarreau:
>> Here's some more recent projects that probably grew up with GitHub. I
>> can't comment how they do the backports, though:
>>
>> https://github.com/nodejs/node/issues (has LTS / Edge)
>> https://github.com/zfsonlinux/zfs/issues (has stable /
Am 09.01.2019 um 15:22 schrieb Willy Tarreau:
> Hi Tim,
>
> On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote:
>> Am 09.01.19 um 05:31 schrieb Willy Tarreau:
>>> Except that the "naturally" part here is manually performed by someone,
>>> and an issue tracker is nothing more than an
Hi Tim,
On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote:
> Am 09.01.19 um 05:31 schrieb Willy Tarreau:
> > Except that the "naturally" part here is manually performed by someone,
> > and an issue tracker is nothing more than an organized todo list, which
> > *is* useful to remind
Willy,
Am 09.01.19 um 05:31 schrieb Willy Tarreau:
> Except that the "naturally" part here is manually performed by someone,
> and an issue tracker is nothing more than an organized todo list, which
> *is* useful to remind that you missed some backports. It regularly happens
> to us, like when
On Tue, Jan 08, 2019 at 07:18:07PM +0100, Tim Düsterhus wrote:
> Willy,
>
> Am 08.01.19 um 18:30 schrieb Willy Tarreau:
> > I totally agree. This is the tool I'm missing the most currently. I'm
> > not aware of a *good* and manageable issue tracker. Having a status for
> > a bug per branch most
Willy,
Am 08.01.19 um 18:30 schrieb Willy Tarreau:
> I totally agree. This is the tool I'm missing the most currently. I'm
> not aware of a *good* and manageable issue tracker. Having a status for
> a bug per branch most likely eliminates most of them...
I'm not sure this is required. The
On Sun, Jan 06, 2019 at 07:41:08PM +0300, Alexey Elymanov wrote:
> Ansible, for example (https://github.com/ansible/ansible/issues), uses some
> advanced automation and templates to manage their enormous issues stream.
> Issue are checked against conforming rules/tests/codestyle checks or, for
>
Hi guys,
sorry for the long delay, it was not the best week for me to restart
all of this discussion, but now it's OK, I'm catching up!
On Sun, Jan 06, 2019 at 05:29:43PM +0100, Lukas Tribus wrote:
> Hello everyone,
>
>
> as per Tim's suggestion I'm restarting the discussion about the issue
>
Ansible, for example (https://github.com/ansible/ansible/issues), uses some
advanced automation and templates to manage their enormous issues stream.
Issue are checked against conforming rules/tests/codestyle checks or, for
example, automatically closed due inactivity
I believe most if not all
25 matches
Mail list logo
