Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> All: Please share your experiences, positive and negative, with project
> management frameworks. Ideally it covers patches, discussions,
> bugtracking and is accessible and usable at least via web browser.

I think a few people have said they like github, but it gets objected to
because of certain reasons and I do not want to start a discussion on
those.

I did find a project called gogs (go git service) which has an ui just like
github's. Maybe this would be a solution worth exploring.

As for the "I like to use email thing": I like to reply via email to PR's and
issues too, the only downside I can think of for people liking the email
workflow would be creating a PR involves pressing the "Create PR"
button in the web gui. (If I haven't thought of other downsides please
let me know ;)
Fetching peoples patchsets through git is simple, and there is
the possiblility of adding forks of people that contribute regularly as
git remotes (to make fetching and review even simpler).

The only thing I don't like about github/gogs from an UI perspective is the
merge button. The merge button creates unnecessary merge commits
which I don't like, and many projects agree to not use the merge button.
There is no way to disable it, but I think that disabling it in gogs would be
trivial.

[0] https://gogs.io

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> The only thing I don't like about github/gogs from an UI perspective is the
> merge button. The merge button creates unnecessary merge commits
> which I don't like, and many projects agree to not use the merge button.
> There is no way to disable it, but I think that disabling it in gogs would be
> trivial.

If people are open to trying gogs (which I haven't yet) we could also make
the merge button add a Signed-off-by: field to the commit message and
use git merge --ff-only. (I'd be willing to look into this)

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

David Craven <david@craven.ch> writes:

>> All: Please share your experiences, positive and negative, with project
>> management frameworks. Ideally it covers patches, discussions,
>> bugtracking and is accessible and usable at least via web browser.
>
> I think a few people have said they like github, but it gets objected to
> because of certain reasons and I do not want to start a discussion on
> those.
>
> I did find a project called gogs (go git service) which has an ui just like
> github's. Maybe this would be a solution worth exploring.
>
> As for the "I like to use email thing": I like to reply via email to PR's and
> issues too, the only downside I can think of for people liking the email
> workflow would be creating a PR involves pressing the "Create PR"
> button in the web gui. (If I haven't thought of other downsides please
> let me know ;)

> Fetching peoples patchsets through git is simple, and there is
> the possiblility of adding forks of people that contribute regularly as
> git remotes (to make fetching and review even simpler).

This reminds me of my personal workflow in a small package maintaining
project which looks like this (just to give some more input on this,
this is obviously not ideal to scale up to the size of guix.. maybe):

Distributed instances of the git repository, everybody works on a
checkout local to them, every persons instances is a remote you pull
from and do the work to keep them in sync. Discussion happens on psyced.org.
The post-receive hook sends a notice to a psyced server which
distributes it to people subscribed to the channel (git2psyc hook).
This only works for small groups where everybody is competent enough not
to mess up the work.

> The only thing I don't like about github/gogs from an UI perspective is the
> merge button. The merge button creates unnecessary merge commits
> which I don't like, and many projects agree to not use the merge button.
> There is no way to disable it, but I think that disabling it in gogs would be
> trivial.
>
> [0] https://gogs.io

-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Pjotr Prins]

I hope this will be a topic in Rennes though I won't be there.

Savannah is nice but limited in scope (and notably does not provide
100% uptime). 

The E-mail patch system is archaic and is certainly noisy. I think we
should have an additional system that is more friendly. I use github a
lot to collaborate, and while it is not acceptable to a GNU project
(mostly because it is closed source), it certainly proves to have good
functionality and improves collaboration.

Also, I think reviewers should become mentors - i.e., help rather than
be only critical. The current system is unfriendly, though it appears
to be hard to appreciate that problem from the 'inside'. The main
problem appears to be we have too few reviewers to make them
mentors...

I am not contributing my work as it stands. Maybe my contributions do
not matter in the greater scheme of things - but, believe me, I am not
happy about it. I just updated a critical bug in OpenBLAS and bumped
scipy and numpy in production. Someone else will have to do that work
over again.

Maybe some people here can form a working group and come up with
recommendations?

Pj.

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

Hi,

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> I hope this will be a topic in Rennes though I won't be there.

I won't be there as well, it's currently too expensive for me.

> Savannah is nice but limited in scope (and notably does not provide
> 100% uptime). 
>
> The E-mail patch system is archaic and is certainly noisy. I think we
> should have an additional system that is more friendly. I use github a
> lot to collaborate, and while it is not acceptable to a GNU project
> (mostly because it is closed source), it certainly proves to have good
> functionality and improves collaboration.
>
> Also, I think reviewers should become mentors - i.e., help rather than
> be only critical. The current system is unfriendly, though it appears
> to be hard to appreciate that problem from the 'inside'. The main
> problem appears to be we have too few reviewers to make them
> mentors...
>
> I am not contributing my work as it stands. Maybe my contributions do
> not matter in the greater scheme of things - but, believe me, I am not
> happy about it. I just updated a critical bug in OpenBLAS and bumped
> scipy and numpy in production. Someone else will have to do that work
> over again.
>
> Maybe some people here can form a working group and come up with
> recommendations?

I'd be happy to join or work in such a group.

> Pj.

-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> I am not contributing my work as it stands.

I thought you where going to do some awesome work on adding and
finding 3rd party guix repos? ;-)

Things that I need before using guixsd on my laptop is firmware, atom
and chrome or chromium. But as I understand it chromium isn't going to
be accepted because of addons, so it's probably easier to patchelf the
deb release. So I'm really looking forward to your work in this
area...

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Pjotr Prins]

On Mon, Aug 15, 2016 at 03:39:27AM +0200, David Craven wrote:
> I thought you where going to do some awesome work on adding and
> finding 3rd party guix repos? ;-)
> 
> Things that I need before using guixsd on my laptop is firmware, atom
> and chrome or chromium. But as I understand it chromium isn't going to
> be accepted because of addons, so it's probably easier to patchelf the
> deb release. So I'm really looking forward to your work in this
> area...

I still like the idea of distributed source repos. You may also have
noticed there was resistance to that idea.

Let's see what happens in the coming months. No need to rush it.

Pj.

-- 

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> I still like the idea of distributed source repos. You may also have
> noticed there was resistance to that idea.

I thought that the resistance was towards stabilizing an internal api,
which I'm also against. But I'll have to reread the thread more
carefully if you see things differently. I think where there is change
there is resistance, but can understand that based on your previous
experiences you are distrustful of the process and don't want to
commit to doing the work upfront...

@ng0: Sorry for hijacking the thread =)

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 806 bytes --]

Am 13.08.2016 um 12:46 schrieb David Craven:
> I think a few people have said they like github, but it gets objected to
> because of certain reasons and I do not want to start a discussion on
> those.

A good alternative could be to use gitlab, which one could host on one's
own systems. It is "only" MIT licensed, but at least "open source" - in
contrast to github, which is propritary.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/feiertagsarbeit-bei-teletrust
Kolumne:
http://www.cissp-gefluester.de/2012-04-compliance-bringt-keine-sicherheit


[-- Attachment #1.2: Type: text/html, Size: 1978 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Danny Milosavljevic]

On Mon, 15 Aug 2016 13:53:49 +0200
Hartmut Goebel <h.goebel@goebel-consult.de> wrote:

> A good alternative could be to use gitlab, which one could host on one's
> own systems. It is "only" MIT licensed, but at least "open source" - in
> contrast to github, which is propritary.

I second the gitlab recommendation. I have multiple servers that use gitlab and it's very nice. It supports merge requests, continuous integration buiulds etc.

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Alex Vong]

Hi guixers,

Actually, We have GNU Ethical Repository Criteria Evaluations
<https://www.gnu.org/software/repo-criteria-evaluation.html>, which was
published recently (about 1 yr ago).

Below is my understanding of the evaluations:

The essence of the criteria
<https://www.gnu.org/software/repo-criteria.html> is that, web service
is different from software, we (as users) cannot modify the software on
other's server. So, it is not about free or non-free. Rather, it is
about other ethical issues, e.g. privacy, accept users from all
countries...

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Mon, 15 Aug 2016 13:53:49 +0200
> Hartmut Goebel <h.goebel@goebel-consult.de> wrote:
>
>> A good alternative could be to use gitlab, which one could host on one's
>> own systems. It is "only" MIT licensed, but at least "open source" - in
>> contrast to github, which is propritary.
>
> I second the gitlab recommendation. I have multiple servers that use
> gitlab and it's very nice. It supports merge requests, continuous
> integration buiulds etc.

Agree, if we were to host it on our own server, then we simply need to
follow the criteria and be done with it. Of course, there are other
alternatives, such as gogs, which is used by `notabug.org'.

Cheers,
Alex

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 1019 bytes --]

Am 15.08.2016 um 17:18 schrieb Alex Vong:
> Of course, there are other alternatives, such as gogs,

The gogs.io website is using a lot of external content, namely from
google and jquery. The FAQ is hosted a another external side, discus.
Gogs is not even self-hosting gogs but hosted at github. gogs.io does
not even state which license it has ("Open Source It all at guithub"),

So there would be at least some work to be done to fulfil the "B"
criteria "Does not report visitors to other organizations"

(I have to admit that I did not check this for gitlab, though.)

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/warum-sie-nicht-perl-programmiern-sollten
Kolumne:
http://www.cissp-gefluester.de/2011-09-kommerz-uber-recht-fdp-die-gefaellt-mir-partei



[-- Attachment #1.2: Type: text/html, Size: 2211 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

>> I still like the idea of distributed source repos. You may also have
>> noticed there was resistance to that idea.
>
> I thought that the resistance was towards stabilizing an internal api,
> which I'm also against. But I'll have to reread the thread more
> carefully if you see things differently. I think where there is change
> there is resistance, but can understand that based on your previous
> experiences you are distrustful of the process and don't want to
> commit to doing the work upfront...

I don’t think that “resistance” is a fair description of the discussion
around that feature.  The result was an actual proposal that could be
implemented.

See this email:

   http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01156.html

~~ Ricardo

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Pjotr Prins]

On Tue, Aug 16, 2016 at 03:17:11PM +0200, Ricardo Wurmus wrote:
> I don’t think that “resistance” is a fair description of the discussion
> around that feature.  The result was an actual proposal that could be
> implemented.

Yeah, not accurate is my bad. Pros and cons were mentioned. I'll find
some time after summer to work on this. I think it is important
enough.

Pj.

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Alex Vong]

Hartmut Goebel <h.goebel@goebel-consult.de> writes:

> Am 15.08.2016 um 17:18 schrieb Alex Vong:
>
>     Of course, there are other alternatives, such as gogs,
>
> The gogs.io website is using a lot of external content, namely from
> google and jquery. The FAQ is hosted a another external side, discus.
> Gogs is not even self-hosting gogs but hosted at github. gogs.io does
> not even state which license it has ("Open Source It all at guithub"),
>
I am a bit confused here, are we going to (1) host the code on our own
server, or (2) using code-hosting service provided by other
organization?

If we are doing (1), then it is up to us to meet the GNU ethical
repository criteria [0]. If we are doing (2), then we need to ensure
that our service provider meet the criteria [0].

What I suggested is doing (1) with gogs. Do I understand the situation
correctly? WDYT?

> So there would be at least some work to be done to fulfil the "B"
> criteria "Does not report visitors to other organizations"
>
> (I have to admit that I did not check this for gitlab, though.)

[0]: https://www.gnu.org/software/repo-criteria.en.html

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 1512 bytes --]

Am 16.08.2016 um 16:06 schrieb Alex Vong:
> Hartmut Goebel <h.goebel@goebel-consult.de> writes:
>
>> The gogs.io website is using a lot of external content, namely from
>> google and jquery. The FAQ is hosted a another external side, discus.
>> Gogs is not even self-hosting gogs but hosted at github. gogs.io does
>> not even state which license it has ("Open Source It all at guithub"),
>>
> I am a bit confused here, are we going to (1) host the code on our own
> server, or (2) using code-hosting service provided by other
> organization?
>
> [...]
> What I suggested is doing (1) with gogs. Do I understand the situation
> correctly? WDYT?

Sorry for the confusion. Of course I also suggest doing (1). My
objection is just about gogs website: They are using content from other
sites. If we host it ourself, we'd need to take care about this - and
need to re-check this on every update. Otherwise we would "report
visitors to other organizations", which would prevent to get "B" grade
in then GNU Ethical Repository Criteria Evaluations.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/kleiner-erfahrungsbericht-mit-online-ocr-diensten

Kolumne:
http://www.cissp-gefluester.de/2012-01-in-die-cloud-in-die-cloud-aber-wo-soll-die-sein



[-- Attachment #1.2: Type: text/html, Size: 2953 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

Hartmut Goebel <h.goebel@goebel-consult.de> writes:

> [ Unknown signature status ]
> Am 16.08.2016 um 16:06 schrieb Alex Vong:
>> Hartmut Goebel <h.goebel@goebel-consult.de> writes:
>>
>>> The gogs.io website is using a lot of external content, namely from
>>> google and jquery. The FAQ is hosted a another external side, discus.
>>> Gogs is not even self-hosting gogs but hosted at github. gogs.io does
>>> not even state which license it has ("Open Source It all at guithub"),
>>>
>> I am a bit confused here, are we going to (1) host the code on our own
>> server, or (2) using code-hosting service provided by other
>> organization?
>>
>> [...]
>> What I suggested is doing (1) with gogs. Do I understand the situation
>> correctly? WDYT?
>
> Sorry for the confusion. Of course I also suggest doing (1). My
> objection is just about gogs website: They are using content from other
> sites. If we host it ourself, we'd need to take care about this - and
> need to re-check this on every update. Otherwise we would "report
> visitors to other organizations", which would prevent to get "B" grade
> in then GNU Ethical Repository Criteria Evaluations.
>

Multiple times gitlab was mentioned,

it seems that gitlab can not be used because we require enterprise:
https://lists.gnu.org/archive/html/guix-devel/2016-08/msg02152.html

I keep searching and trying out systems, but it almost seems like to
meet a consent where everyone gets what they want, it needs to be
written. Of course it could be better if we would not have around 32
regular contributors and only around 3 regular reviewers, but for people
who approached me outside of the official channels Email is much more
than just an annoyance, it's impossible for them to contribute due to
various reasons.

I remember using kallithea for a while, but I don't know how good or bad
it was, which features it had. I need to setup an instance and see
what's it like.
It's sauce is here: https://kallithea-scm.org/repos/kallithea
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

ng0 <ng0@we.make.ritual.n0.is> writes:

> it seems that gitlab can not be used because we require enterprise:
> https://lists.gnu.org/archive/html/guix-devel/2016-08/msg02152.html
>
> I keep searching and trying out systems, but it almost seems like to
> meet a consent where everyone gets what they want, it needs to be
> written. Of course it could be better if we would not have around 32
> regular contributors and only around 3 regular reviewers, but for people
> who approached me outside of the official channels Email is much more
> than just an annoyance, it's impossible for them to contribute due to
> various reasons.
>
> I remember using kallithea for a while, but I don't know how good or bad
> it was, which features it had. I need to setup an instance and see
> what's it like.
> It's sauce is here: https://kallithea-scm.org/repos/kallithea

I asked in their irc chat, and issues/bug tracking is (somewhere) on the
roadmap, but currently not being worked on.

My further 2cts:

- Mantis[0] has some nice features and is in general good to work, but I
  don't know about the administration, if it's easy to maintain.

- perl, debian (some of their projects), nasa, and lots of others are
  using RT (request tracker[1]). My only contact with it was at the perl
  side as a bug reporter. It provided me with a way to report bugs even
  without signing up, in the webbrowser.


Ultimately, it's not about the software but about reviewing. I want a
section "reviewing" in the manual, and in my opinion we should
encourage contributors to review and give them the right tools to do so.
My translation from the original IT/GER text to english takes a while,
but there's a nice article someone wrote about a certain topic which can
be applied here in our situation.
For the moment I think everyone who can should (but not must) review at
least 1 patch per month or even per week.
I think that's the best way to solve the situation right now, right
here with what we have. Take a patch, review it, one burden taken from
the backs of the usual ~3 suspects (reviewers).

The problem is the current tool for the distribution of the messages
(the framework of applications known as email). It does not include ways
to take the burden of management of your own backs. It does not help you
to sort, prioritize, filter, highlight, assign $person to $job etc, the
framework itself is minimal. You need to apply many hours of work and
search to get the right tool(s) for the jobs email doesn't do. I want
this burden gone for those who do not want it or can't deal with it
otherwise, lower the amount of information you are required to process
per month if you start contribution.

I begin to suspect that what I want has not been written, like in
several other cases I ran into in the last years.

[0] http://www.mantisbt.org , https://en.wikipedia.org/wiki/Mantis_Bug_Tracker
[1] https://bestpractical.com/request-tracker
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Thu, Sep 01, 2016 at 11:19:00AM +0000, ng0 wrote:

     I begin to suspect that what I want has not been written, like in
     several other cases I ran into in the last years.
     

I suspect it is more a case of not being able to agree on one.

I have found, in the past, that aegis is a great tool for managing the kind of
work we do.   Amongst other things, code review and tests are built into the
design - and not tagged on as an afterthought.  And it is designed to ensure
an "always works" policy.  A real "continuous integration" tool, which is a
term which is banded about so much these days, but rarely actually done.


Unfortunately, aegis is difficult to introduce to a project - not for technical 
reasons - but social ones.  My attempts have often resulted in people complaining
that the thing is "defective" because it won't allow them to do what they want (ie commit 
without review/build/test).

J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

John Darrington <john@darrington.wattle.id.au> writes:

> [ Unknown signature status ]
> On Thu, Sep 01, 2016 at 11:19:00AM +0000, ng0 wrote:
>
>      I begin to suspect that what I want has not been written, like in
>      several other cases I ran into in the last years.


What I meant here, and before that, will get too offtopic at the
moment. Eventually I will have an article translated which I can
reference in a text. (For those fluent in those two languages, this is
what I mean: http://my.pages.de/convivenza.it ,
http://my.pages.de/convivenza.de )

In this case "has not been written": I'm thinking about a completely
distributed version control system, serverless, but there are issues I
do not understand at the moment and can not put my full attention
to. I have some ideas outlined, and some annoyances every system I used
so far had (namechanges for examples). This is also why I am packaging
darcs to look at pijul and so on.

> I suspect it is more a case of not being able to agree on one.
>
> I have found, in the past, that aegis is a great tool for managing the kind of
> work we do.   Amongst other things, code review and tests are built into the
> design - and not tagged on as an afterthought.  And it is designed to ensure
> an "always works" policy.  A real "continuous integration" tool, which is a
> term which is banded about so much these days, but rarely actually done.
>
>
> Unfortunately, aegis is difficult to introduce to a project - not for technical 
> reasons - but social ones.  My attempts have often resulted in people complaining
> that the thing is "defective" because it won't allow them to do what they want (ie commit 
> without review/build/test).
>
> J'

This sounds interesting. Is there a demo instance somewhere?

> -- 
> Avoid eavesdropping.  Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Alex Vong]

Hi,


I think I share the same concern as you do, currently the mailing list
is too crowded and it is difficult to find the relevant bit. Below are
my opinions on it:


While it may not be as user-friendly as web-based bug tracker these
days, I think the Debian bug tracking system is still better than our
current approach. In Debian, everything is a package. It is like a
language primitive in the bug tracker system.


There is an "intended to package" (ITP) package. When you want to
package something, you simply file a bug against the ITP package. This
has the advantage that, the relevant information stays within the bug
report. So everyone can see the whole process, starting from someone
intending to package, to a fully reviewed package, all in a single bug
report. It is like having "lexical scoping".


And the most important argument comes: We already have it now[0]! So,
this could be a working intermediate solution. Currently, we are not
using debbugs to its full potential.


My suggestion will be to create a new package called "guix-package", and
all people hoping to introduce a new package to guix should file a bug
report to <bug-guix-package@gnu.org>. If you are new to this type of bug
tracking system, no problem! There is (some) documentation on it[1][2]
and here is my own little example[3].


Hope this make sence!


Cheers,
Alex


[0]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
[1]: https://debbugs.gnu.org/Reporting.html
[2]: https://debbugs.gnu.org/server-control.html
[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24352

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[ng0]

Alex Vong <alexvong1995@gmail.com> writes:

> Hi,
>
>
> I think I share the same concern as you do, currently the mailing list
> is too crowded and it is difficult to find the relevant bit. Below are
> my opinions on it:
>
>
> While it may not be as user-friendly as web-based bug tracker these
> days, I think the Debian bug tracking system is still better than our
> current approach. In Debian, everything is a package. It is like a
> language primitive in the bug tracker system.
>
>
> There is an "intended to package" (ITP) package. When you want to
> package something, you simply file a bug against the ITP package. This
> has the advantage that, the relevant information stays within the bug
> report. So everyone can see the whole process, starting from someone
> intending to package, to a fully reviewed package, all in a single bug
> report. It is like having "lexical scoping".
>
>
> And the most important argument comes: We already have it now[0]! So,
> this could be a working intermediate solution. Currently, we are not
> using debbugs to its full potential.
>
>
> My suggestion will be to create a new package called "guix-package", and
> all people hoping to introduce a new package to guix should file a bug
> report to <bug-guix-package@gnu.org>. If you are new to this type of bug
> tracking system, no problem! There is (some) documentation on it[1][2]
> and here is my own little example[3].
>
>
> Hope this make sence!
>
>
> Cheers,
> Alex
>
>
> [0]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
> [1]: https://debbugs.gnu.org/Reporting.html
> [2]: https://debbugs.gnu.org/server-control.html
> [3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24352

Interesting, this is close to the Gentoo system: Everything is a bug.
Which means, every update, every bug, every new package, every "our
infrastructure server XYZ broke" request, etc.

In a recent bug report through debbugs at Guix side I was not able to
figure out how to close the bug at all. I think if this isn't covered
good enough in upstream docs, we should 1. point it out at our side and
then 2. improve upstream documentation as the email sent when you open
the bug should state how you close the bug again..
I'll report this bug upstream and try to fix it if it's hasn't caught
their attention and it still exists - maybe gnu.org version just happens
to be outdated.

I think this could really work out.. It would also establish some kind
of work flow, where currently we have one, but you are rather free in
how it all works out.
This would also help to avoid parallel work. Someone wanted to package
pybitmessage while I already had pybitmessage packaged, things like
that.

Appending to my previous email, as John did not provide a link this is
the Aegis which was meant: http://aegis.sourceforge.net/

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Alex Vong]

ng0 <ng0@n0.is> writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Hi,
>>
>>
>> I think I share the same concern as you do, currently the mailing list
>> is too crowded and it is difficult to find the relevant bit. Below are
>> my opinions on it:
>>
>>
>> While it may not be as user-friendly as web-based bug tracker these
>> days, I think the Debian bug tracking system is still better than our
>> current approach. In Debian, everything is a package. It is like a
>> language primitive in the bug tracker system.
>>
>>
>> There is an "intended to package" (ITP) package. When you want to
>> package something, you simply file a bug against the ITP package. This
>> has the advantage that, the relevant information stays within the bug
>> report. So everyone can see the whole process, starting from someone
>> intending to package, to a fully reviewed package, all in a single bug
>> report. It is like having "lexical scoping".
>>
>>
>> And the most important argument comes: We already have it now[0]! So,
>> this could be a working intermediate solution. Currently, we are not
>> using debbugs to its full potential.
>>
>>
>> My suggestion will be to create a new package called "guix-package", and
>> all people hoping to introduce a new package to guix should file a bug
>> report to <bug-guix-package@gnu.org>. If you are new to this type of bug
>> tracking system, no problem! There is (some) documentation on it[1][2]
>> and here is my own little example[3].
>>
>>
>> Hope this make sence!
>>
>>
>> Cheers,
>> Alex
>>
>>
>> [0]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
>> [1]: https://debbugs.gnu.org/Reporting.html
>> [2]: https://debbugs.gnu.org/server-control.html
>> [3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24352
>
> Interesting, this is close to the Gentoo system: Everything is a bug.
> Which means, every update, every bug, every new package, every "our
> infrastructure server XYZ broke" request, etc.
>
> In a recent bug report through debbugs at Guix side I was not able to
> figure out how to close the bug at all. I think if this isn't covered
> good enough in upstream docs, we should 1. point it out at our side and
> then 2. improve upstream documentation as the email sent when you open
> the bug should state how you close the bug again..
> I'll report this bug upstream and try to fix it if it's hasn't caught
> their attention and it still exists - maybe gnu.org version just happens
> to be outdated.
>
Indeed, documentation on the BTS is quite lacking. Looking at the bottom
of page, the last page is last modified on 31 Dec 2009, which isn't
update for quite a while. Maybe we can have a wiki page on libreplanet
like this one[0]. Anyone know how to add a new page on libreplanet wiki?
(The earlier discussion regarding icecat and tor browser could also have
its own page.)

To close a bug, sending email to <BUGNUMBER-done@debbugs.gnu.org>
should work in theory, but I haven't try it yet.

> I think this could really work out.. It would also establish some kind
> of work flow, where currently we have one, but you are rather free in
> how it all works out.
> This would also help to avoid parallel work. Someone wanted to package
> pybitmessage while I already had pybitmessage packaged, things like
> that.
>
Please Feel free to discuss. Here is only my initial thought (heavily
borrowed from debian):
  1. File bug report to <bug-guix-package@debbugs.org> with the title
  being "PACKAGENAME@VERSION".(It can be changed later via bug control.)
  The content of the bug report should mention the license of the
  software.
  2. Patch reviewing and responding are done by sending email to
  <BUGNUMBER@debbugs.gnu.org>.
  3. Bug report is closed when patch is pushed (we could even automate
  this one).
  
Note that this does not account for patches which does not bump the
version, maybe we should keep the bug report of version N opened and
only close it when version N+1 is pushed. What do you and the others
think?

> Appending to my previous email, as John did not provide a link this is
> the Aegis which was meant: http://aegis.sourceforge.net/

[0]: https://wiki.debian.org/HowtoUseBTS

Tracking package submissions with Debbugs

[Ludovic Courtès]

Hi Alex!

Alex Vong <alexvong1995@gmail.com> skribis:

> While it may not be as user-friendly as web-based bug tracker these
> days, I think the Debian bug tracking system is still better than our
> current approach. In Debian, everything is a package. It is like a
> language primitive in the bug tracker system.
>
>
> There is an "intended to package" (ITP) package. When you want to
> package something, you simply file a bug against the ITP package. This
> has the advantage that, the relevant information stays within the bug
> report. So everyone can see the whole process, starting from someone
> intending to package, to a fully reviewed package, all in a single bug
> report. It is like having "lexical scoping".

And we all like lexical scoping.  :-)

> And the most important argument comes: We already have it now[0]! So,
> this could be a working intermediate solution. Currently, we are not
> using debbugs to its full potential.
>
>
> My suggestion will be to create a new package called "guix-package", and
> all people hoping to introduce a new package to guix should file a bug
> report to <bug-guix-package@gnu.org>. If you are new to this type of bug
> tracking system, no problem! There is (some) documentation on it[1][2]
> and here is my own little example[3].

I think this is a good idea, at least an improvement over the status
quo.

I suppose it wouldn’t handle patch series very well though, would it?
Or people would have to send the “cover letter” of the series first, and
then send the rest to NNN@debbugs.gnu.org once a number has been
assigned?

What’s unclear to me is how convenient Debbugs is for non-Emacs users:
Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
how do non-Emacs users deal with Debbugs?

Thanks,
Ludo’.

Re: Tracking package submissions with Debbugs

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> I suppose it wouldn’t handle patch series very well though, would it?
> Or people would have to send the “cover letter” of the series first, and
> then send the rest to NNN@debbugs.gnu.org once a number has been
> assigned?

Or could we have a bug per module?  Then the whole patch series could be
sent to the bug id of the module.  But I guess this would make it harder
to keep track of individual package submissions again, because bug would
rarely ever be closed when there are lots of patches to the same module.

> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
> how do non-Emacs users deal with Debbugs?

Outside of Emacs I only ever used Debbugs in read-only fashion.  The web
interface is not very pretty but it’s functional and looks better than
the default mailman interface.

~~ Ricardo

Re: Tracking package submissions with Debbugs

[Alex Vong]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> I suppose it wouldn’t handle patch series very well though, would it?
>> Or people would have to send the “cover letter” of the series first, and
>> then send the rest to NNN@debbugs.gnu.org once a number has been
>> assigned?
>
> Or could we have a bug per module?  Then the whole patch series could be
> sent to the bug id of the module.  But I guess this would make it harder
> to keep track of individual package submissions again, because bug would
> rarely ever be closed when there are lots of patches to the same module.
>
Yes, I think it will make it harder to keep track of individual
package. Is there a way to configure git-sendmail to do what we want?

Here is a related idea. If we were to send all packaging bug reports to
a single package (e.g. guix-package), then it will make it impossible to
browse from a web browser. The situation is similar to the slowness of
our Packages page[0]. So instead of having a bug per module, should we
have a package per module (e.g. guix-package-emacs, guix-package-maths,
guix-package-shells ...)?

>> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
>> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
>> how do non-Emacs users deal with Debbugs?
>
> Outside of Emacs I only ever used Debbugs in read-only fashion.  The web
> interface is not very pretty but it’s functional and looks better than
> the default mailman interface.
>
Yes, it is still email-based. The web interface is read-only, you can
search for bug reports in a package[1]. To reply to it, you send email
to <XXXXX-bug-guix-package@debbugs.org>. For non-emacs users, this means
they have to use email client to communicate and web browser to search /
read bugs.

> ~~ Ricardo

[0]: https://www.gnu.org/software/guix/packages/
[1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Aemacs;package=guix

Re: Tracking package submissions with Debbugs

[Ludovic Courtès]

Alex Vong <alexvong1995@gmail.com> skribis:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> I suppose it wouldn’t handle patch series very well though, would it?
>>> Or people would have to send the “cover letter” of the series first, and
>>> then send the rest to NNN@debbugs.gnu.org once a number has been
>>> assigned?
>>
>> Or could we have a bug per module?  Then the whole patch series could be
>> sent to the bug id of the module.  But I guess this would make it harder
>> to keep track of individual package submissions again, because bug would
>> rarely ever be closed when there are lots of patches to the same module.
>>
> Yes, I think it will make it harder to keep track of individual
> package. Is there a way to configure git-sendmail to do what we want?
>
> Here is a related idea. If we were to send all packaging bug reports to
> a single package (e.g. guix-package), then it will make it impossible to
> browse from a web browser. The situation is similar to the slowness of
> our Packages page[0]. So instead of having a bug per module, should we
> have a package per module (e.g. guix-package-emacs, guix-package-maths,
> guix-package-shells ...)?

I think that wouldn’t scale, and would also prevent us to have a global
view of all the pending submissions (not to mention that debbugs.gnu.org
is administered by non-Guix people and they’d quickly be annoyed ;-)).

So, let’s ask for guix-package@gnu.org (or guix-patches@gnu.org?) to
begin with?

>>> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
>>> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
>>> how do non-Emacs users deal with Debbugs?
>>
>> Outside of Emacs I only ever used Debbugs in read-only fashion.  The web
>> interface is not very pretty but it’s functional and looks better than
>> the default mailman interface.
>>
> Yes, it is still email-based. The web interface is read-only, you can
> search for bug reports in a package[1]. To reply to it, you send email
> to <XXXXX-bug-guix-package@debbugs.org>. For non-emacs users, this means
> they have to use email client to communicate and web browser to search /
> read bugs.

Yeah well, better than the Mailman interface.

Thanks,
Ludo’.

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Pjotr Prins]

Today was pretty much an E-mail overload on the ML. In itself amazing
:)

Pj.

On Fri, Sep 02, 2016 at 06:54:47PM +0800, Alex Vong wrote:
> ng0 <ng0@n0.is> writes:
> 
> > Alex Vong <alexvong1995@gmail.com> writes:
> >
> >> Hi,
> >>
> >>
> >> I think I share the same concern as you do, currently the mailing list
> >> is too crowded and it is difficult to find the relevant bit. Below are
> >> my opinions on it:
> >>
> >>
> >> While it may not be as user-friendly as web-based bug tracker these
> >> days, I think the Debian bug tracking system is still better than our
> >> current approach. In Debian, everything is a package. It is like a
> >> language primitive in the bug tracker system.
> >>
> >>
> >> There is an "intended to package" (ITP) package. When you want to
> >> package something, you simply file a bug against the ITP package. This
> >> has the advantage that, the relevant information stays within the bug
> >> report. So everyone can see the whole process, starting from someone
> >> intending to package, to a fully reviewed package, all in a single bug
> >> report. It is like having "lexical scoping".
> >>
> >>
> >> And the most important argument comes: We already have it now[0]! So,
> >> this could be a working intermediate solution. Currently, we are not
> >> using debbugs to its full potential.
> >>
> >>
> >> My suggestion will be to create a new package called "guix-package", and
> >> all people hoping to introduce a new package to guix should file a bug
> >> report to <bug-guix-package@gnu.org>. If you are new to this type of bug
> >> tracking system, no problem! There is (some) documentation on it[1][2]
> >> and here is my own little example[3].
> >>
> >>
> >> Hope this make sence!
> >>
> >>
> >> Cheers,
> >> Alex
> >>
> >>
> >> [0]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
> >> [1]: https://debbugs.gnu.org/Reporting.html
> >> [2]: https://debbugs.gnu.org/server-control.html
> >> [3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24352
> >
> > Interesting, this is close to the Gentoo system: Everything is a bug.
> > Which means, every update, every bug, every new package, every "our
> > infrastructure server XYZ broke" request, etc.
> >
> > In a recent bug report through debbugs at Guix side I was not able to
> > figure out how to close the bug at all. I think if this isn't covered
> > good enough in upstream docs, we should 1. point it out at our side and
> > then 2. improve upstream documentation as the email sent when you open
> > the bug should state how you close the bug again..
> > I'll report this bug upstream and try to fix it if it's hasn't caught
> > their attention and it still exists - maybe gnu.org version just happens
> > to be outdated.
> >
> Indeed, documentation on the BTS is quite lacking. Looking at the bottom
> of page, the last page is last modified on 31 Dec 2009, which isn't
> update for quite a while. Maybe we can have a wiki page on libreplanet
> like this one[0]. Anyone know how to add a new page on libreplanet wiki?
> (The earlier discussion regarding icecat and tor browser could also have
> its own page.)
> 
> To close a bug, sending email to <BUGNUMBER-done@debbugs.gnu.org>
> should work in theory, but I haven't try it yet.
> 
> > I think this could really work out.. It would also establish some kind
> > of work flow, where currently we have one, but you are rather free in
> > how it all works out.
> > This would also help to avoid parallel work. Someone wanted to package
> > pybitmessage while I already had pybitmessage packaged, things like
> > that.
> >
> Please Feel free to discuss. Here is only my initial thought (heavily
> borrowed from debian):
>   1. File bug report to <bug-guix-package@debbugs.org> with the title
>   being "PACKAGENAME@VERSION".(It can be changed later via bug control.)
>   The content of the bug report should mention the license of the
>   software.
>   2. Patch reviewing and responding are done by sending email to
>   <BUGNUMBER@debbugs.gnu.org>.
>   3. Bug report is closed when patch is pushed (we could even automate
>   this one).
>   
> Note that this does not account for patches which does not bump the
> version, maybe we should keep the bug report of version N opened and
> only close it when version N+1 is pushed. What do you and the others
> think?
> 
> > Appending to my previous email, as John did not provide a link this is
> > the Aegis which was meant: http://aegis.sourceforge.net/
> 
> [0]: https://wiki.debian.org/HowtoUseBTS
> 

-- 

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> Today was pretty much an E-mail overload on the ML. In itself amazing :)

I agree. If you aren't a full time guix developer it's hard to keep
up. The only way I can keep up is by marking the emails I'm not
interested in quickly as read =P Just reading all emails is a time
commitment in itself...

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Brendan Tildesley]

On 2016-09-04 02:55, David Craven wrote:
>> Today was pretty much an E-mail overload on the ML. In itself amazing :)
> I agree. If you aren't a full time guix developer it's hard to keep
> up. The only way I can keep up is by marking the emails I'm not
> interested in quickly as read =P Just reading all emails is a time
> commitment in itself...
>
I was going to post a patch over several files removing redundant
mkdir-p expressions,

but decided against it! If you run something like  `ack '\(install-file'
-B 7| ack  'mkdir-p' -A 7'

You can see them, since install-file already contains a mkdir-p. Also It
seems like

(let ((out  (assoc-ref outputs "out")))...) is set in almost every
package definition,

as if having some symbol for the outputs already might be more efficient??

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[David Craven]

> I was going to post a patch over several files removing redundant
> mkdir-p expressions,

> but decided against it! If you run something like  `ack '\(install-file'
> -B 7| ack  'mkdir-p' -A 7'

> You can see them, since install-file already contains a mkdir-p.

I think this is going a little off-topic.

> Also It seems like

> (let ((out  (assoc-ref outputs "out")))...) is set in almost every
> package definition,

> as if having some symbol for the outputs already might be more efficient??

If we start special-casing stuff, in no time we'll have a dozen
special cases. I think that that makes package definitions harder to
read. As it is currently there are a couple of primitives that do a
good job for defining packages without obfuscating stuff. I think
Ricardo already replied to this on IRC ;)

Re: Feedback, ideas, discussion: tracking patches, discussions, bugs.

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Sun, Sep 04, 2016 at 05:19:45AM +1000, Brendan Tildesley wrote:
> On 2016-09-04 02:55, David Craven wrote:
> >> Today was pretty much an E-mail overload on the ML. In itself amazing :)
> > I agree. If you aren't a full time guix developer it's hard to keep
> > up. The only way I can keep up is by marking the emails I'm not
> > interested in quickly as read =P Just reading all emails is a time
> > commitment in itself...
> >
> I was going to post a patch over several files removing redundant
> mkdir-p expressions,
> 
> but decided against it! If you run something like  `ack '\(install-file'
> -B 7| ack  'mkdir-p' -A 7'
> 
> You can see them, since install-file already contains a mkdir-p. Also It
> seems like
> 
> (let ((out  (assoc-ref outputs "out")))...) is set in almost every
> package definition,
> 
> as if having some symbol for the outputs already might be more efficient??
> 

If its just one I sometime just use %outputs, but this also only works
when the only output is "out". We don't want too much "special magic" in
the packaging definitions also.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Tracking package submissions with Debbugs

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]

On Fri, Sep 02, 2016 at 02:39:12PM +0200, Ludovic Courtès wrote:
> Hi Alex!
> 
> Alex Vong <alexvong1995@gmail.com> skribis:
> 
> > While it may not be as user-friendly as web-based bug tracker these
> > days, I think the Debian bug tracking system is still better than our
> > current approach. In Debian, everything is a package. It is like a
> > language primitive in the bug tracker system.
> >
> >
> > There is an "intended to package" (ITP) package. When you want to
> > package something, you simply file a bug against the ITP package. This
> > has the advantage that, the relevant information stays within the bug
> > report. So everyone can see the whole process, starting from someone
> > intending to package, to a fully reviewed package, all in a single bug
> > report. It is like having "lexical scoping".
> 
> And we all like lexical scoping.  :-)

I think it would make sense to have the one bug report for the "target
package" and then all the packages that get pulled in along the way get
tacked on also.

> 
> > And the most important argument comes: We already have it now[0]! So,
> > this could be a working intermediate solution. Currently, we are not
> > using debbugs to its full potential.
> >
> >
> > My suggestion will be to create a new package called "guix-package", and
> > all people hoping to introduce a new package to guix should file a bug
> > report to <bug-guix-package@gnu.org>. If you are new to this type of bug
> > tracking system, no problem! There is (some) documentation on it[1][2]
> > and here is my own little example[3].
> 
> I think this is a good idea, at least an improvement over the status
> quo.
> 
> I suppose it wouldn’t handle patch series very well though, would it?
> Or people would have to send the “cover letter” of the series first, and
> then send the rest to NNN@debbugs.gnu.org once a number has been
> assigned?
> 

This seems like the best idea, otherwise we'd have to reassign and merge
all the patches.

> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
> how do non-Emacs users deal with Debbugs?
> 

This is one of my concerns. There's reportbug (and reportbug-ng) in
Debian https://reportbug-ng.alioth.debian.org/index.html that we might
be able to use after forking/patching our info in for Debian's.

> Thanks,
> Ludo’.
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Tracking package submissions with Debbugs

[Alex Vong]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> I suppose it wouldn’t handle patch series very well though, would it?
>>>> Or people would have to send the “cover letter” of the series first, and
>>>> then send the rest to NNN@debbugs.gnu.org once a number has been
>>>> assigned?
>>>
>>> Or could we have a bug per module?  Then the whole patch series could be
>>> sent to the bug id of the module.  But I guess this would make it harder
>>> to keep track of individual package submissions again, because bug would
>>> rarely ever be closed when there are lots of patches to the same module.
>>>
>> Yes, I think it will make it harder to keep track of individual
>> package. Is there a way to configure git-sendmail to do what we want?
>>
>> Here is a related idea. If we were to send all packaging bug reports to
>> a single package (e.g. guix-package), then it will make it impossible to
>> browse from a web browser. The situation is similar to the slowness of
>> our Packages page[0]. So instead of having a bug per module, should we
>> have a package per module (e.g. guix-package-emacs, guix-package-maths,
>> guix-package-shells ...)?
>
> I think that wouldn’t scale, and would also prevent us to have a global
> view of all the pending submissions (not to mention that debbugs.gnu.org
> is administered by non-Guix people and they’d quickly be annoyed ;-)).
>
> So, let’s ask for guix-package@gnu.org (or guix-patches@gnu.org?) to
> begin with?
>
I see. Right now, emacs has about 3766 non-archived bugs, and it takes
12 - 15 seconds to load the bug page in tor browser / firefox, which is
still acceptable. Guix now has about 3958 packages, so I will guess it
will take similar time to load? 

About scalibility, I also find that the split will make it difficult to
search for a particular package, since the web-based interface only
support for searching up to 2 packages at once. So yes, I think we
should ask for guix-package@gnu.org to begin.

>>>> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
>>>> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
>>>> how do non-Emacs users deal with Debbugs?
>>>
>>> Outside of Emacs I only ever used Debbugs in read-only fashion.  The web
>>> interface is not very pretty but it’s functional and looks better than
>>> the default mailman interface.
>>>
>> Yes, it is still email-based. The web interface is read-only, you can
>> search for bug reports in a package[1]. To reply to it, you send email
>> to <XXXXX-bug-guix-package@debbugs.org>. For non-emacs users, this means
>> they have to use email client to communicate and web browser to search /
>> read bugs.
>
> Yeah well, better than the Mailman interface.
>
I forget to mention: This reminds me of the old joke: Emacs is an
operating system that needs a better editor :)

> Thanks,
> Ludo’.

Re: Tracking package submissions with Debbugs

[Alex Vong]

Efraim Flashner <efraim@flashner.co.il> writes:

> On Fri, Sep 02, 2016 at 02:39:12PM +0200, Ludovic Courtès wrote:
>> Hi Alex!
>> 
>> Alex Vong <alexvong1995@gmail.com> skribis:
>> 
>> > While it may not be as user-friendly as web-based bug tracker these
>> > days, I think the Debian bug tracking system is still better than our
>> > current approach. In Debian, everything is a package. It is like a
>> > language primitive in the bug tracker system.
>> >
>> >
>> > There is an "intended to package" (ITP) package. When you want to
>> > package something, you simply file a bug against the ITP package. This
>> > has the advantage that, the relevant information stays within the bug
>> > report. So everyone can see the whole process, starting from someone
>> > intending to package, to a fully reviewed package, all in a single bug
>> > report. It is like having "lexical scoping".
>> 
>> And we all like lexical scoping.  :-)
>
> I think it would make sense to have the one bug report for the "target
> package" and then all the packages that get pulled in along the way get
> tacked on also.
>
Hmm, but what if we have 2 target packages (A, B) pulling the same
package (C) in? Then it is not obvious if C should live in A's or B's
bug report. What do you think?

>> 
>> > And the most important argument comes: We already have it now[0]! So,
>> > this could be a working intermediate solution. Currently, we are not
>> > using debbugs to its full potential.
>> >
>> >
>> > My suggestion will be to create a new package called "guix-package", and
>> > all people hoping to introduce a new package to guix should file a bug
>> > report to <bug-guix-package@gnu.org>. If you are new to this type of bug
>> > tracking system, no problem! There is (some) documentation on it[1][2]
>> > and here is my own little example[3].
>> 
>> I think this is a good idea, at least an improvement over the status
>> quo.
>> 
>> I suppose it wouldn’t handle patch series very well though, would it?
>> Or people would have to send the “cover letter” of the series first, and
>> then send the rest to NNN@debbugs.gnu.org once a number has been
>> assigned?
>> 
>
> This seems like the best idea, otherwise we'd have to reassign and merge
> all the patches.
>
>> What’s unclear to me is how convenient Debbugs is for non-Emacs users:
>> Emacs has M-x debbugs-gnu, which is a significant UI improvement, but
>> how do non-Emacs users deal with Debbugs?
>> 
>
> This is one of my concerns. There's reportbug (and reportbug-ng) in
> Debian https://reportbug-ng.alioth.debian.org/index.html that we might
> be able to use after forking/patching our info in for Debian's.
>
Perhaps we can have guix reportbug!

>> Thanks,
>> Ludo’.
>> 

Re: Tracking package submissions with Debbugs

[Andreas Enge]

Hello,

using debbugs corresponds to a suggestion I made a while ago, so I am
obviously in favour of it...

On Sun, Sep 04, 2016 at 10:37:02AM +0800, Alex Vong wrote:
> > I think it would make sense to have the one bug report for the "target
> > package" and then all the packages that get pulled in along the way get
> > tacked on also.
> Hmm, but what if we have 2 target packages (A, B) pulling the same
> package (C) in? Then it is not obvious if C should live in A's or B's
> bug report. What do you think?

I do not quite understand the problem with relating bug reports to packages.
The discussion sounds as if we considered one constantly open bug report per
package, which is maybe a misunderstanding on my part. I would say that bug
reports should correspond roughly to our current discussion threads on
guix-devel: Someone sends in a patch or patch series, which opens a new bug
(there seems to be the problem of git-sendmail still); there are replies back
and forth; in the end the patch is applied (or, from time to time, retracted),
and the bug is closed. In this way, we have an overview of pending patches
and are less likely to forget one.

As for the non-emacs users, I intend to work as before: Subscribe to all the
bugs and have them end up in my mailbox, reply, and potentially close them
by mail.

Andreas

Re: Tracking package submissions with Debbugs

[ng0]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> using debbugs corresponds to a suggestion I made a while ago, so I am
> obviously in favour of it...
>
> On Sun, Sep 04, 2016 at 10:37:02AM +0800, Alex Vong wrote:
>> > I think it would make sense to have the one bug report for the "target
>> > package" and then all the packages that get pulled in along the way get
>> > tacked on also.
>> Hmm, but what if we have 2 target packages (A, B) pulling the same
>> package (C) in? Then it is not obvious if C should live in A's or B's
>> bug report. What do you think?
>
> I do not quite understand the problem with relating bug reports to packages.
> The discussion sounds as if we considered one constantly open bug report per
> package, which is maybe a misunderstanding on my part. I would say that bug
> reports should correspond roughly to our current discussion threads on
> guix-devel: Someone sends in a patch or patch series, which opens a new bug
> (there seems to be the problem of git-sendmail still); there are replies back
> and forth; in the end the patch is applied (or, from time to time, retracted),
> and the bug is closed. In this way, we have an overview of pending patches
> and are less likely to forget one.
>
> As for the non-emacs users, I intend to work as before: Subscribe to all the
> bugs and have them end up in my mailbox, reply, and potentially close them
> by mail.
>
> Andreas
>

A constant open bug could be confusing and misleading. Is this really
what they mean? My preference would be:

User sends email with patch (or coverletter, wait for assignment*),
patch gets assigned id, all correspondence regarding that bug is done in
that thread, bug is considered/marked as done when the patch is merged.


* which can be contra-productive as debbugs email to arrive at my side
  sometimes take 12 - 24 hours
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[ng0]

Resend because somehow this ended up being send from my unsubscribed
address:

ng0 <ng0@n0.is> writes:

> Andreas Enge <andreas@enge.fr> writes:
>
>> Hello,
>>
>> using debbugs corresponds to a suggestion I made a while ago, so I am
>> obviously in favour of it...
>>
>> On Sun, Sep 04, 2016 at 10:37:02AM +0800, Alex Vong wrote:
>>> > I think it would make sense to have the one bug report for the "target
>>> > package" and then all the packages that get pulled in along the way get
>>> > tacked on also.
>>> Hmm, but what if we have 2 target packages (A, B) pulling the same
>>> package (C) in? Then it is not obvious if C should live in A's or B's
>>> bug report. What do you think?
>>
>> I do not quite understand the problem with relating bug reports to packages.
>> The discussion sounds as if we considered one constantly open bug report per
>> package, which is maybe a misunderstanding on my part. I would say that bug
>> reports should correspond roughly to our current discussion threads on
>> guix-devel: Someone sends in a patch or patch series, which opens a new bug
>> (there seems to be the problem of git-sendmail still); there are replies back
>> and forth; in the end the patch is applied (or, from time to time, retracted),
>> and the bug is closed. In this way, we have an overview of pending patches
>> and are less likely to forget one.
>>
>> As for the non-emacs users, I intend to work as before: Subscribe to all the
>> bugs and have them end up in my mailbox, reply, and potentially close them
>> by mail.
>>
>> Andreas
>>
>
> A constant open bug could be confusing and misleading. Is this really
> what they mean? My preference would be:
>
> User sends email with patch (or coverletter, wait for assignment*),
> patch gets assigned id, all correspondence regarding that bug is done in
> that thread, bug is considered/marked as done when the patch is merged.
>
>
> * which can be contra-productive as debbugs email to arrive at my side
>   sometimes take 12 - 24 hours
> -- 
> ng0
> For non-prism friendly talk find me on http://www.psyced.org
>

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[David Craven]

Why is the gitlab not including the rebase feature a deal breaker?
It's open source, so disabling the merge button in the ui isn't a big
deal. We can continue using git push like we've been doing so far...

Also I've mentioned previously - why not gogs - but I'm ok with either.

Re: Tracking package submissions with Debbugs

[Alex Kost]

David Craven (2016-09-04 20:09 +0300) wrote:

> Why is the gitlab not including the rebase feature a deal breaker?

I'm wondering too.

> It's open source, so disabling the merge button in the ui isn't a big
> deal. We can continue using git push like we've been doing so far...

I also don't see a problem, it's just a missing button in the web
interface, and it doesn't prevent us from using "git rebase" or whatever
is needed to adjust a patch before pushing it to the guix repo.

-- 
Alex

Re: Tracking package submissions with Debbugs

[Ludovic Courtès]

Hello!

Alex Kost <alezost@gmail.com> skribis:

> David Craven (2016-09-04 20:09 +0300) wrote:
>
>> Why is the gitlab not including the rebase feature a deal breaker?
>
> I'm wondering too.
>
>> It's open source, so disabling the merge button in the ui isn't a big
>> deal. We can continue using git push like we've been doing so far...
>
> I also don't see a problem, it's just a missing button in the web
> interface, and it doesn't prevent us from using "git rebase" or whatever
> is needed to adjust a patch before pushing it to the guix repo.

What I would like to ensure is that:

  1. Our commit history is not full of merges of tiny branches, which is
     what GitHub (and I thought Gitlab) encourages.

  2. Contributors can revise their patch series (by rewriting history of
     that series), and committers can incorporate the final patch set,
     rather than the whole sequence of iterations.  This is what we
     currently do; Gitlab should be able to recognize such patterns and
     notice that the “merge request” can be closed, for instance.

  3. People (especially, ahem, me!) can work from the comfort of their
     favorite editor/terminal, or at least without having to run lots of
     JS code and clicking around all day long.

I haven’t used Gitlab so I don’t know whether these requirements are
satisfied.  If you set up an instance of Gitlab-free-software-edition
and we do not have these problems, I’m happy!  :-)

Ludo’.

Re: Tracking package submissions with Debbugs

[David Craven]

> 1. Our commit history is not full of merges of tiny branches, which is
>     what GitHub (and I thought Gitlab) encourages.

Yes, that is right. But as I mentioned in a different thread, there
are many projects where the maintainers agree to not use the merge
button because of this. Since we are using gitlab we can actually go
further than an agreement and disable the merge button entirely.

>   2. Contributors can revise their patch series (by rewriting history of
>      that series), and committers can incorporate the final patch set,
>      rather than the whole sequence of iterations.  This is what we
>      currently do; Gitlab should be able to recognize such patterns and
>      notice that the “merge request” can be closed, for instance.

It depends on how much modification the maintainers make before
pushing. It's git that has to recognize the commits as being the same.
If a contributor can rebase his branch after the PR was merged without
getting any conflicts, gitlab will also recognize that the PR was
merged. Since it's a lot easier to iterate without spamming the
mailing list we can in practice ask contributors to fix issues like
indentation themselves, and if the worst case happens, PR can be
closed manually (in the web interface).

>   3. People (especially, ahem, me!) can work from the comfort of their
>      favorite editor/terminal, or at least without having to run lots of
>      JS code and clicking around all day long.

That's what we all want. The only time it's required to use the web
interface is when creating a new issue or a new PR. After that you can
reply via email, rebase and push via git.

> I haven’t used Gitlab so I don’t know whether these requirements are
> satisfied.  If you set up an instance of Gitlab-free-software-edition
> and we do not have these problems, I’m happy!  :-)

Some adjustments to the workflow might have to be made, but I think we
have to give it a test run of at least a week or two before throwing
the towel ;-)

Who wants to take on this? Any volunteers?

Re: Tracking package submissions with Debbugs

[ng0]

David Craven <david@craven.ch> writes:

>> 1. Our commit history is not full of merges of tiny branches, which is
>>     what GitHub (and I thought Gitlab) encourages.
>
> Yes, that is right. But as I mentioned in a different thread, there
> are many projects where the maintainers agree to not use the merge
> button because of this. Since we are using gitlab we can actually go
> further than an agreement and disable the merge button entirely.
>
>>   2. Contributors can revise their patch series (by rewriting history of
>>      that series), and committers can incorporate the final patch set,
>>      rather than the whole sequence of iterations.  This is what we
>>      currently do; Gitlab should be able to recognize such patterns and
>>      notice that the “merge request” can be closed, for instance.
>
> It depends on how much modification the maintainers make before
> pushing. It's git that has to recognize the commits as being the same.
> If a contributor can rebase his branch after the PR was merged without
> getting any conflicts, gitlab will also recognize that the PR was
> merged. Since it's a lot easier to iterate without spamming the
> mailing list we can in practice ask contributors to fix issues like
> indentation themselves, and if the worst case happens, PR can be
> closed manually (in the web interface).
>
>>   3. People (especially, ahem, me!) can work from the comfort of their
>>      favorite editor/terminal, or at least without having to run lots of
>>      JS code and clicking around all day long.
>
> That's what we all want. The only time it's required to use the web
> interface is when creating a new issue or a new PR. After that you can
> reply via email, rebase and push via git.
>
>> I haven’t used Gitlab so I don’t know whether these requirements are
>> satisfied.  If you set up an instance of Gitlab-free-software-edition
>> and we do not have these problems, I’m happy!  :-)
>
> Some adjustments to the workflow might have to be made, but I think we
> have to give it a test run of at least a week or two before throwing
> the towel ;-)
>
> Who wants to take on this? Any volunteers?

How would we proceed with this? One of us sets up a gitlab instance on a
server under their control?
I could volunteer for a test run.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[ng0]

> Who wants to take on this? Any volunteers?

On second note, my server is intentionally very minimal, so I have to
look at if gitlab will be fully functional (email etc).
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[David Craven]

> How would we proceed with this?

I think that someone needs to write a service for gitlab first, since
we probably want to deploy it using guixsd ;) Then probably Ludo will
take over this. To give this a fair shot it has to be at least as much
effort to revert to the old way of things as to continue with the new
system.

Re: Tracking package submissions with Debbugs

[Ben Woodcroft]

Hi ng0,

On 06/09/16 09:17, ng0 wrote:
>> Who wants to take on this? Any volunteers?
> On second note, my server is intentionally very minimal, so I have to
> look at if gitlab will be fully functional (email etc).

Did you have any success working with Kallithea? It seems on the face of 
it to be the most free-software and appropriate of the tools listed at 
the below Wikipedia link, but I don't have any experience with it.
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities

ben

Re: Tracking package submissions with Debbugs

[Alex Vong]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> using debbugs corresponds to a suggestion I made a while ago, so I am
> obviously in favour of it...
>
> On Sun, Sep 04, 2016 at 10:37:02AM +0800, Alex Vong wrote:
>> > I think it would make sense to have the one bug report for the "target
>> > package" and then all the packages that get pulled in along the way get
>> > tacked on also.
>> Hmm, but what if we have 2 target packages (A, B) pulling the same
>> package (C) in? Then it is not obvious if C should live in A's or B's
>> bug report. What do you think?
>
> I do not quite understand the problem with relating bug reports to packages.
> The discussion sounds as if we considered one constantly open bug report per
> package, which is maybe a misunderstanding on my part. I would say that bug
> reports should correspond roughly to our current discussion threads on
> guix-devel: Someone sends in a patch or patch series, which opens a new bug
> (there seems to be the problem of git-sendmail still); there are replies back
> and forth; in the end the patch is applied (or, from time to time, retracted),
> and the bug is closed. In this way, we have an overview of pending patches
> and are less likely to forget one.
>
My original thought is to have a bug report per version, so people can
easily search for the packaging history for a particular version. But it
sounds like your idea is better than mine, having an overview of pending
patches is more important.

> As for the non-emacs users, I intend to work as before: Subscribe to all the
> bugs and have them end up in my mailbox, reply, and potentially close them
> by mail.
>
I think per-bug subsciption is not working right now[0]. Do you know of
any good alternatives?

> Andreas

[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439

Re: Tracking package submissions with Debbugs

[ng0]

Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> Hi ng0,
>
> On 06/09/16 09:17, ng0 wrote:
>>> Who wants to take on this? Any volunteers?
>> On second note, my server is intentionally very minimal, so I have to
>> look at if gitlab will be fully functional (email etc).
>
> Did you have any success working with Kallithea? It seems on the face of 
> it to be the most free-software and appropriate of the tools listed at 
> the below Wikipedia link, but I don't have any experience with it.
> https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities
>
> ben


I'm working
(https://gitlab.com/packaging-guix/guix-kallithea/commits/master) on it
and this
https://bitbucket.org/conservancy/kallithea/issues/244/license-issue-in-your-dependency-graph
is where I am stuck at the moment.

Also Kallithea does have an issues tracker on their roadmap, but it is
not being worked on at the moment (I asked in their irc channel).

At the same time I'm working on darcs, gogs and a go build-system and
all kinds of other things. From packaging I don't know what gitlab
wants as I have not looked at it. But gogs and kallithea both look
easy to handle... gogs just needs a go build-system to make it easier to
package the dependencies.

I'm personally working with SaaSs as mirror for some of my repositories
and using plain git daemon without any web index for the rest.

I don't know if this is what you asked about.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[David Craven]

> Also Kallithea does have an issues tracker on their roadmap, but it is
> not being worked on at the moment (I asked in their irc channel).
>
> At the same time I'm working on darcs, gogs and a go build-system and
> all kinds of other things. From packaging I don't know what gitlab
> wants as I have not looked at it. But gogs and kallithea both look
> easy to handle... gogs just needs a go build-system to make it easier to
> package the dependencies.

I guess whoever writes the service has some say in which one to use...
Everyone else is just talking not doing =P

Re: Tracking package submissions with Debbugs

[Ludovic Courtès]

ng0 <ng0@we.make.ritual.n0.is> skribis:

> David Craven <david@craven.ch> writes:
>
>>> 1. Our commit history is not full of merges of tiny branches, which is
>>>     what GitHub (and I thought Gitlab) encourages.
>>
>> Yes, that is right. But as I mentioned in a different thread, there
>> are many projects where the maintainers agree to not use the merge
>> button because of this. Since we are using gitlab we can actually go
>> further than an agreement and disable the merge button entirely.
>>
>>>   2. Contributors can revise their patch series (by rewriting history of
>>>      that series), and committers can incorporate the final patch set,
>>>      rather than the whole sequence of iterations.  This is what we
>>>      currently do; Gitlab should be able to recognize such patterns and
>>>      notice that the “merge request” can be closed, for instance.
>>
>> It depends on how much modification the maintainers make before
>> pushing. It's git that has to recognize the commits as being the same.
>> If a contributor can rebase his branch after the PR was merged without
>> getting any conflicts, gitlab will also recognize that the PR was
>> merged. Since it's a lot easier to iterate without spamming the
>> mailing list we can in practice ask contributors to fix issues like
>> indentation themselves, and if the worst case happens, PR can be
>> closed manually (in the web interface).
>>
>>>   3. People (especially, ahem, me!) can work from the comfort of their
>>>      favorite editor/terminal, or at least without having to run lots of
>>>      JS code and clicking around all day long.
>>
>> That's what we all want. The only time it's required to use the web
>> interface is when creating a new issue or a new PR. After that you can
>> reply via email, rebase and push via git.
>>
>>> I haven’t used Gitlab so I don’t know whether these requirements are
>>> satisfied.  If you set up an instance of Gitlab-free-software-edition
>>> and we do not have these problems, I’m happy!  :-)
>>
>> Some adjustments to the workflow might have to be made, but I think we
>> have to give it a test run of at least a week or two before throwing
>> the towel ;-)

Sure.  Thanks David for clarifying.

>> Who wants to take on this? Any volunteers?
>
> How would we proceed with this? One of us sets up a gitlab instance on a
> server under their control?
> I could volunteer for a test run.

Fine with me!

Ludo’.