Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/22/2017 03:25 PM, Eliezer Croitoru wrote:
> Then it's also +1 for me to close for now

Done (a week ago).


> but promote the README.md which will redirect users to the bugzilla..


Please review the following README changes that are meant to address
(albeit indirectly) your request to promote Bugzilla:

  https://github.com/squid-cache/squid/pull/33

To see the updated README with Github rendering, visit

https://github.com/measurement-factory/squid/tree/github-friendlier-readme


Thank you,

Alex.


> -Original Message-
> From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of 
> Kinkie
> Sent: Saturday, July 22, 2017 18:16
> To: Alex Rousskov <rouss...@measurement-factory.com>
> Cc: Squid Developers <squid-dev@lists.squid-cache.org>
> Subject: Re: [squid-dev] [RFC] Disable Github issue tracker
> 
> I also agree to close Issues for the time being. We can always reopen them 
> later on if it'll be deemed useful.
> 
> On Fri, Jul 21, 2017 at 5:37 PM, Alex Rousskov 
> <rouss...@measurement-factory.com> wrote:
>> On 07/21/2017 10:15 AM, Amos Jeffries wrote:
>>> Alex would you like to draw up a formal announcement email to go out 
>>> to people not on squid-dev about the change having been done?
>>>  I'm thinking squid-announce/squid-users and the blog.
>>
>> I can, but I do not recommend announcing anything and posting 
>> README.md until we decide on the Github Issues status. Both of those 
>> documents (and user actions) would be affected by this important 
>> migration-related decision.
>>
>> So far, only three people voiced their opinions:
>>
>>   + For immediate Issues closure: Amos, Alex.
>>   - Against immediate Issues closure: Eliezer.
>>
>> While the current tally is technically enough for me to put my foot 
>> down and disable Github Issues, it would be nice to have at least one 
>> more supporting opinion for a more meaningful "consensus" declaration.
>>
>> Alex.
>> ___
>> squid-dev mailing list
>> squid-dev@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-dev
> 
> 
> 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Eliezer Croitoru]

Then it's also +1 for me to close for now but promote the README.md which will 
redirect users to the bugzilla..

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of 
Kinkie
Sent: Saturday, July 22, 2017 18:16
To: Alex Rousskov <rouss...@measurement-factory.com>
Cc: Squid Developers <squid-dev@lists.squid-cache.org>
Subject: Re: [squid-dev] [RFC] Disable Github issue tracker

I also agree to close Issues for the time being. We can always reopen them 
later on if it'll be deemed useful.

On Fri, Jul 21, 2017 at 5:37 PM, Alex Rousskov 
<rouss...@measurement-factory.com> wrote:
> On 07/21/2017 10:15 AM, Amos Jeffries wrote:
>> Alex would you like to draw up a formal announcement email to go out 
>> to people not on squid-dev about the change having been done?
>>  I'm thinking squid-announce/squid-users and the blog.
>
> I can, but I do not recommend announcing anything and posting 
> README.md until we decide on the Github Issues status. Both of those 
> documents (and user actions) would be affected by this important 
> migration-related decision.
>
> So far, only three people voiced their opinions:
>
>   + For immediate Issues closure: Amos, Alex.
>   - Against immediate Issues closure: Eliezer.
>
> While the current tally is technically enough for me to put my foot 
> down and disable Github Issues, it would be nice to have at least one 
> more supporting opinion for a more meaningful "consensus" declaration.
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev



-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Kinkie]

I also agree to close Issues for the time being. We can always reopen
them later on if it'll be deemed useful.

On Fri, Jul 21, 2017 at 5:37 PM, Alex Rousskov
 wrote:
> On 07/21/2017 10:15 AM, Amos Jeffries wrote:
>> Alex would you like to draw up a formal announcement email to go out to
>> people not on squid-dev about the change having been done?
>>  I'm thinking squid-announce/squid-users and the blog.
>
> I can, but I do not recommend announcing anything and posting README.md
> until we decide on the Github Issues status. Both of those documents
> (and user actions) would be affected by this important migration-related
> decision.
>
> So far, only three people voiced their opinions:
>
>   + For immediate Issues closure: Amos, Alex.
>   - Against immediate Issues closure: Eliezer.
>
> While the current tally is technically enough for me to put my foot down
> and disable Github Issues, it would be nice to have at least one more
> supporting opinion for a more meaningful "consensus" declaration.
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev



-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/21/2017 10:15 AM, Amos Jeffries wrote:
> Alex would you like to draw up a formal announcement email to go out to
> people not on squid-dev about the change having been done?
>  I'm thinking squid-announce/squid-users and the blog.

I can, but I do not recommend announcing anything and posting README.md
until we decide on the Github Issues status. Both of those documents
(and user actions) would be affected by this important migration-related
decision.

So far, only three people voiced their opinions:

  + For immediate Issues closure: Amos, Alex.
  - Against immediate Issues closure: Eliezer.

While the current tally is technically enough for me to put my foot down
and disable Github Issues, it would be nice to have at least one more
supporting opinion for a more meaningful "consensus" declaration.

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Amos Jeffries]

On 22/07/17 03:08, Alex Rousskov wrote:

On 07/21/2017 12:29 AM, Eliezer Croitoru wrote:


so anyone
that will land into the github repository will be aware that the
project is moving\moved from bzr to github


IMO, that historical fact is rather useless for somebody who is already
on Github, already looking at a live git repository. README.md should
only contain (references to) critically important Squid-specific
information IMO.



On roughly that topic.

Alex would you like to draw up a formal announcement email to go out to 
people not on squid-dev about the change having been done?

 I'm thinking squid-announce/squid-users and the blog.

Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/21/2017 12:29 AM, Eliezer Croitoru wrote:

> Then if nobody is sending these issues or using then, I believe that
> leaving this section should stay open as a "Chat" and "Connection
> initiation" channel for a month or so.

FWIW, I fail to see a logical connection from "nobody was using X for a
year" to "let's leave X available for another month".

Github Issues are not meant for "chatting" or "project connection
initiation". "Nobody" is using them that way across Github. We can try
to force people to use our Issues in our special, novel way, but that
seems like a doomed strategy for a project that does not receive much
attention.

If we leave Github Issues open, would you volunteer to tell everybody
who "misuse" Issues for bug reports and feature requests to re-file
their issues with Bugzilla, explaining why they need to spend an extra
20 minutes of their time (after they already did a perfectly reasonable
and honorable thing -- filing a well-written bug report in Github Issues)?


> Please take your time to add a README.md to the github repo 

I agree that this should be done.


> so anyone
> that will land into the github repository will be aware that the
> project is moving\moved from bzr to github 

IMO, that historical fact is rather useless for somebody who is already
on Github, already looking at a live git repository. README.md should
only contain (references to) critically important Squid-specific
information IMO.


Cheers,

Alex.


> -Original Message-
> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
> Sent: Friday, July 21, 2017 07:57
> To: Eliezer Croitoru <elie...@ngtech.co.il>; squid-dev@lists.squid-cache.org
> Subject: Re: [squid-dev] [RFC] Disable Github issue tracker
> 
> On 07/20/2017 02:48 PM, Eliezer Croitoru wrote:
> 
>> github cab mainly be related to coding
> 
> Since no automation can enforce that kind of separation, we would have to do 
> it manually, which will both annoy posters (confused by an unusual
> split) and drain our resources.
> 
> 
>> If I(a programmer) already have an account at github, why should I 
>> open a new account just to start interacting with the Squid-Cache 
>> project?
> 
> You are probably assuming that Bugzilla cannot accept github logins.
> This is not my area of expertise, but I believe that Bugzilla can be 
> configured to do so (natively or via extensions).
> 
> 
>> What do you think about the idea of leaving the issues section open?
> 
> FWIW, Github issues were open for more than a year, without attracting any 
> significant contributions. I would be surprised if they suddenly start doing 
> so now.
> 
> 
>> Or maybe we are not looking for such audience?
> 
> IMHO, we are.
> 
> 
> Cheers,
> 
> Alex.
> 
> 
> 
>> -Original Message-
>> From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
>> Sent: Thursday, July 20, 2017 20:35
>> To: Eliezer Croitoru <elie...@ngtech.co.il>; 
>> squid-dev@lists.squid-cache.org
>> Subject: Re: [squid-dev] [RFC] Disable Github issue tracker
>>
>> On 07/20/2017 01:25 AM, Eliezer Croitoru wrote:
>>> Can we allow issues access to specific users?
>>
>> AFAIK no. We can restrict certain issue updates (e.g., comment editing) but 
>> not issue reading and issue creation.
>>
>>
>>> I believe that the right place to have a "TODO" or similar notes as a 
>>> github issue might be a good thing.
>>> I think that the Bugzilla has much to offer then github issues so +1 for 
>>> staying with the Bugzilla, but maybe try to utilize issues for code 
>>> specific things and to allow only specific users get access to it.
>>>
>>
>> What is the essential difference between a code-specific TODO/note and a 
>> feature request that makes only the former category benefit from using 
>> Github Issues?
>>
>> Alex.
>>
> 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Eliezer Croitoru]

Then if nobody is sending these issues or using then, I believe that leaving 
this section should stay open as a "Chat" and "Connection initiation" channel 
for a month or so.
Also if it's doable to integrate github accounts with the bugzilla it would be 
pretty good thing to do.

And last but not least:
Please take your time to add a README.md to the github repo so anyone that will 
land into the github repository will be aware that the project is moving\moved 
from bzr to github and maybe add couple links of the project and couple other 
important things.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
Sent: Friday, July 21, 2017 07:57
To: Eliezer Croitoru <elie...@ngtech.co.il>; squid-dev@lists.squid-cache.org
Subject: Re: [squid-dev] [RFC] Disable Github issue tracker

On 07/20/2017 02:48 PM, Eliezer Croitoru wrote:

> github cab mainly be related to coding

Since no automation can enforce that kind of separation, we would have to do it 
manually, which will both annoy posters (confused by an unusual
split) and drain our resources.


> If I(a programmer) already have an account at github, why should I 
> open a new account just to start interacting with the Squid-Cache 
> project?

You are probably assuming that Bugzilla cannot accept github logins.
This is not my area of expertise, but I believe that Bugzilla can be configured 
to do so (natively or via extensions).


> What do you think about the idea of leaving the issues section open?

FWIW, Github issues were open for more than a year, without attracting any 
significant contributions. I would be surprised if they suddenly start doing so 
now.


> Or maybe we are not looking for such audience?

IMHO, we are.


Cheers,

Alex.



> -Original Message-
> From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
> Sent: Thursday, July 20, 2017 20:35
> To: Eliezer Croitoru <elie...@ngtech.co.il>; 
> squid-dev@lists.squid-cache.org
> Subject: Re: [squid-dev] [RFC] Disable Github issue tracker
> 
> On 07/20/2017 01:25 AM, Eliezer Croitoru wrote:
>> Can we allow issues access to specific users?
> 
> AFAIK no. We can restrict certain issue updates (e.g., comment editing) but 
> not issue reading and issue creation.
> 
> 
>> I believe that the right place to have a "TODO" or similar notes as a github 
>> issue might be a good thing.
>> I think that the Bugzilla has much to offer then github issues so +1 for 
>> staying with the Bugzilla, but maybe try to utilize issues for code specific 
>> things and to allow only specific users get access to it.
>>
> 
> What is the essential difference between a code-specific TODO/note and a 
> feature request that makes only the former category benefit from using Github 
> Issues?
> 
> Alex.
> 


___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/20/2017 02:48 PM, Eliezer Croitoru wrote:

> github cab mainly be related to coding

Since no automation can enforce that kind of separation, we would have
to do it manually, which will both annoy posters (confused by an unusual
split) and drain our resources.


> If I(a programmer) already have an account at github, why should I
> open a new account just to start interacting with the Squid-Cache
> project?

You are probably assuming that Bugzilla cannot accept github logins.
This is not my area of expertise, but I believe that Bugzilla can be
configured to do so (natively or via extensions).


> What do you think about the idea of leaving the issues section open?

FWIW, Github issues were open for more than a year, without attracting
any significant contributions. I would be surprised if they suddenly
start doing so now.


> Or maybe we are not looking for such audience?

IMHO, we are.


Cheers,

Alex.



> -Original Message-
> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
> Sent: Thursday, July 20, 2017 20:35
> To: Eliezer Croitoru <elie...@ngtech.co.il>; squid-dev@lists.squid-cache.org
> Subject: Re: [squid-dev] [RFC] Disable Github issue tracker
> 
> On 07/20/2017 01:25 AM, Eliezer Croitoru wrote:
>> Can we allow issues access to specific users?
> 
> AFAIK no. We can restrict certain issue updates (e.g., comment editing) but 
> not issue reading and issue creation.
> 
> 
>> I believe that the right place to have a "TODO" or similar notes as a github 
>> issue might be a good thing.
>> I think that the Bugzilla has much to offer then github issues so +1 for 
>> staying with the Bugzilla, but maybe try to utilize issues for code specific 
>> things and to allow only specific users get access to it.
>>
> 
> What is the essential difference between a code-specific TODO/note and a 
> feature request that makes only the former category benefit from using Github 
> Issues?
> 
> Alex.
> 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Eliezer Croitoru]

Well, what I was thinking is that issues in github cab mainly be related to 
coding and development like what the squid-dev list is.
I understand that technically the Bugzilla and the issues section are not 
different too much, but, we can logically set a rule that issues would be in 
the Squid-Cache project for development related conversations only.

I believe that the much younger programmers are already registered to github so 
it would make sense to use the github issues for these.
I mean: If I(a programmer) already have an account at github, why should I open 
a new account just to start interacting with the Squid-Cache project?
So disabling it completely is good for certain purposes but if the project 
would have a nice README.md with couple guide lines such as:
- To report security vulnerabilities use XYZ
- To make first contact with the development team use the issues section.
- 

Once we decide on the right approach I believe we can start and see what pop in 
the "issues net", maybe it's worth leaving it open just for the sake of 
"solicitation".
(Solicitation these days reminds me of a bug in Golang which prints
"Unsolicited response received on idle HTTP channel..."
https://github.com/golang/go/issues/12855 
One of their biggest bugs I have seen that were not handled for a very long 
time and is relevant specifically to http proxies which uses the native http 
libs )

What do you think about the idea of leaving the issues section open? Or maybe 
we are not looking for such audience?

Eliezer 


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
Sent: Thursday, July 20, 2017 20:35
To: Eliezer Croitoru <elie...@ngtech.co.il>; squid-dev@lists.squid-cache.org
Subject: Re: [squid-dev] [RFC] Disable Github issue tracker

On 07/20/2017 01:25 AM, Eliezer Croitoru wrote:
> Can we allow issues access to specific users?

AFAIK no. We can restrict certain issue updates (e.g., comment editing) but not 
issue reading and issue creation.


> I believe that the right place to have a "TODO" or similar notes as a github 
> issue might be a good thing.
> I think that the Bugzilla has much to offer then github issues so +1 for 
> staying with the Bugzilla, but maybe try to utilize issues for code specific 
> things and to allow only specific users get access to it.
> 

What is the essential difference between a code-specific TODO/note and a 
feature request that makes only the former category benefit from using Github 
Issues?

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/20/2017 01:25 AM, Eliezer Croitoru wrote:
> Can we allow issues access to specific users?

AFAIK no. We can restrict certain issue updates (e.g., comment editing)
but not issue reading and issue creation.


> I believe that the right place to have a "TODO" or similar notes as a github 
> issue might be a good thing.
> I think that the Bugzilla has much to offer then github issues so +1 for 
> staying with the Bugzilla, but maybe try to utilize issues for code specific 
> things and to allow only specific users get access to it.
> 

What is the essential difference between a code-specific TODO/note and a
feature request that makes only the former category benefit from using
Github Issues?

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Eliezer Croitoru]

Can we allow issues access to specific users?
I believe that the right place to have a "TODO" or similar notes as a github 
issue might be a good thing.
I think that the Bugzilla has much to offer then github issues so +1 for 
staying with the Bugzilla, but maybe try to utilize issues for code specific 
things and to allow only specific users get access to it.

And about the questions about branching, git has a very nice branching system.
If needed I will review the git course I took to see if what we need(please 
specific this) can be done\implemented.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of 
Amos Jeffries
Sent: Wednesday, July 19, 2017 06:27
To: squid-dev@lists.squid-cache.org
Subject: Re: [squid-dev] [RFC] Disable Github issue tracker

On 19/07/17 09:22, Alex Rousskov wrote:
> Hello,
> 
>  With Squid official repository now at Github, a lot more folks will
> be tempted to report bugs and file feature requests there. I propose to
> remove that functionality from the Github interface (for now). Any
> objections or better ideas?
> 

Sounds good to me.

  I suspect the issues from Nov/Dec last year have duplicate discussions 
either in squid-users or bugzilla - but that would be worth checking up 
with the submitters before the github issues are lost.

Some other migration things;

a) I have now completed the updates for code maintenance scripts and 
re-enabled the cron jobs.

There are maintainer workflow scripts still todo, but before going to 
the trouble I'm considering whether that workflow still makes any sense 
- it was designed for CVS, and adapted to bzr in absence of good bzr 
tooling. If anyone knows of some good branch management tools for git 
I'm interested.


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/19/2017 06:31 AM, Amos Jeffries wrote:
> On 19/07/17 16:41, Alex Rousskov wrote:
>> On 07/18/2017 09:26 PM, Amos Jeffries wrote:
>>> There are maintainer workflow scripts still todo, but before going to
>>> the trouble I'm considering whether that workflow still makes any sense
>>> - it was designed for CVS, and adapted to bzr in absence of good bzr
>>> tooling. If anyone knows of some good branch management tools for git
>>> I'm interested.

>> I wish I could help, but I do not really know what the old tools did,
>> and do not have enough git expertise to advice on such general topics as
>> "good branch management tools for git". If nobody answers here, consider
>> enumerating the primary needs in general terms. Such a list would make
>> it easier to solicit external advice.

> I was hoping "branch management" might bring up things I'm not
> aware of myself.

Wrong audience, I suppose.


> The tools I have right now are a bunch of scripts that maintain a
> todo-list for each release series, a per-release patch list, and running
> statistics about the quantities of code change.
>  * For each revision/patch in any branch I can mark it as a feature and

>  * For each revision/patch I can see whether it has been cherrypicked
> into an older series (and to what revision in that destination branch),
> and if it is a backport the revision/patch ID in the branch where it
> originated.

If you prefer, the above can be done using PR labels. For example, some
projects use a pair of labels for each backporting target X:

* X-nominated -- somebody wants this PR ported to X; it is not in X
* X-accepted -- maintainer supports the nomination

The four combinations of the above two labels reflect all possible
states of the PR with regard to porting to version X (e.g., a lonely
X-accepted means the PR was ported). Github search can be used to find
PRs to backport.

If you need to remember which non-nominated PRs should not be nominated,
you need another label to mark those (e.g., maintainer-processed).


> group other revisions/patches as delayed fixes to the primary commit.

This important requirement cannot be supported using PR labels. If you
prefer, you can maintain a (specially formatted) Github comment in a
merged PR that accumulates delayed fixes. This will place all
information about the PR in one place.

Needless to say, it is possible to automatically find to-be-ported PRs
and form changesets. Github has an API for querying PRs.


I have no idea whether the above Github hacks are overall better than
what you already have and whether there are better hacks/tooling I do
not know about.

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Amos Jeffries]

On 19/07/17 16:41, Alex Rousskov wrote:

On 07/18/2017 09:26 PM, Amos Jeffries wrote:

On 19/07/17 09:22, Alex Rousskov wrote:

  With Squid official repository now at Github, a lot more folks will
be tempted to report bugs and file feature requests there. I propose to
remove that functionality from the Github interface (for now). Any
objections or better ideas?




Sounds good to me.



I suspect the issues from Nov/Dec last year have duplicate discussions
either in squid-users or bugzilla - but that would be worth checking up
with the submitters before the github issues are lost.


Done. There are two open DevOps issues remaining. I will disable the
interface once those issues are closed. I will try to export/archive the
closed issues before disabling the interface.



There are maintainer workflow scripts still todo, but before going to
the trouble I'm considering whether that workflow still makes any sense
- it was designed for CVS, and adapted to bzr in absence of good bzr
tooling. If anyone knows of some good branch management tools for git
I'm interested.


I wish I could help, but I do not really know what the old tools did,
and do not have enough git expertise to advice on such general topics as
"good branch management tools for git". If nobody answers here, consider
enumerating the primary needs in general terms. Such a list would make
it easier to solicit external advice.



Hmm. Well I was hoping "branch management" might bring up things I'm not 
aware of myself. Oh well.


The tools I have right now are a bunch of scripts that maintain a 
todo-list for each release series, a per-release patch list, and running 
statistics about the quantities of code change.
 * For each revision/patch in any branch I can mark it as a feature and 
group other revisions/patches as delayed fixes to the primary commit.
 * For each revision/patch I can see whether it has been cherrypicked 
into an older series (and to what revision in that destination branch), 
and if it is a backport the revision/patch ID in the branch where it 
originated.





Thank you,

Alex.
P.S. Congratulations on the first PR merge via Github!



LOL. Burden of the maintainership role :-P administrative fixes updating 
various things after major milestones.


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/18/2017 09:26 PM, Amos Jeffries wrote:
> On 19/07/17 09:22, Alex Rousskov wrote:
>>  With Squid official repository now at Github, a lot more folks will
>> be tempted to report bugs and file feature requests there. I propose to
>> remove that functionality from the Github interface (for now). Any
>> objections or better ideas?


> Sounds good to me.

> I suspect the issues from Nov/Dec last year have duplicate discussions
> either in squid-users or bugzilla - but that would be worth checking up
> with the submitters before the github issues are lost.

Done. There are two open DevOps issues remaining. I will disable the
interface once those issues are closed. I will try to export/archive the
closed issues before disabling the interface.


> There are maintainer workflow scripts still todo, but before going to
> the trouble I'm considering whether that workflow still makes any sense
> - it was designed for CVS, and adapted to bzr in absence of good bzr
> tooling. If anyone knows of some good branch management tools for git
> I'm interested.

I wish I could help, but I do not really know what the old tools did,
and do not have enough git expertise to advice on such general topics as
"good branch management tools for git". If nobody answers here, consider
enumerating the primary needs in general terms. Such a list would make
it easier to solicit external advice.


Thank you,

Alex.
P.S. Congratulations on the first PR merge via Github!
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Disable Github issue tracker

[Amos Jeffries]

On 19/07/17 09:22, Alex Rousskov wrote:

Hello,

 With Squid official repository now at Github, a lot more folks will
be tempted to report bugs and file feature requests there. I propose to
remove that functionality from the Github interface (for now). Any
objections or better ideas?



Sounds good to me.

 I suspect the issues from Nov/Dec last year have duplicate discussions 
either in squid-users or bugzilla - but that would be worth checking up 
with the submitters before the github issues are lost.


Some other migration things;

a) I have now completed the updates for code maintenance scripts and 
re-enabled the cron jobs.


There are maintainer workflow scripts still todo, but before going to 
the trouble I'm considering whether that workflow still makes any sense 
- it was designed for CVS, and adapted to bzr in absence of good bzr 
tooling. If anyone knows of some good branch management tools for git 
I'm interested.



Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

Hello,

With Squid official repository now at Github, a lot more folks will
be tempted to report bugs and file feature requests there. I propose to
remove that functionality from the Github interface (for now). Any
objections or better ideas?

FWIW, I have considered and rejected the idea of immediately migrating
from our Bugzilla to the Github issue tracker. Yes, it is tempting to
keep "everything" in one place, and making bug reporting "easy" is a
serious Github advantage, but I do not think we should move right now:

1. Migration itself will not address any current critical problems.

2. Migration is a significant overhead and/or a serious inconvenience,
depending on whether Bugzilla entries are copied to Github or simply
allowed to rot while being "archived" at their current location.

3. Virtually all the primary features missing in Squid Bugzilla today
are either also missing from Github Issues or can be enabled in Bugzilla
by upgrading our Bugzilla installation and adding extensions. This will
not be easy, especially fixing one of the biggest Bugzilla-driven
collaboration limitations[1], but it is doable long-term if we decide to
stay with Bugzilla.


Needless to say, the arguments for staying with Bugzilla and the
decision to stay itself may change in the foreseeable future. We can
revisit this question as needed.


Thank you,

Alex.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=540
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev