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

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

[ng0]

At some point I wanted to reply to the "Subject: none" thread Pjotr
opened. It kept growing and growing, and hit the length where I don't
feel like I want to add to it.
After many years I switched to notmuch for emails, because it all just
sucks. And even with notmuch, it just sucks: I apply tags to emails,
sort emails with tags which are relevant, but it doesn't fix email
itself. And that's the biggest problem I see here. Our communication is
based on a patchset of ancient technologies which require figuring out
how to fix their flaws by choosing the best user agent which does more
than just reading and sending email.
In my opinion we need something which provides *optional* email access
or emacs interface if you want that, but in general uses a framework
with sorting and management built in.
Email does the worst job. Email makes me personally angry. If I have to
tell someone to use a different mail user agent because theirs is
"obviously broken", the problem is not with the application. It's with
Email itself. I could go on about email and corporate networks with
statistics, but this is not my intention here.

On QA, this is okay. We need that like every operating system. As long
as we keep a culture of discussion alive and can talk about problems and
manage to respect our own code of conduct and solve problems, we are
doing a good job.

These are my comments on the part of the thread I've read.
But I want this to be an inspiration for some questions and looking for
a solution to them.


Ludovic: You said you tried various alternatives for patches/bugs etc
tracking in the past 3(?) years of Guix. Can you please summarize what
you remember about the applications you tested, positive and negative
results?

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 want us all to gather experiences, feedback, and ideas and see which
compromises we have to make to get to the point where we solved this big
problem. We'll definitely have to make compromises.
-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org

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.

[David Craven]

> 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.

I don't understand how it's relevant that gogs.io makes use of jquery
and google analytics? It makes sense to not reinvent the wheel and
use 3rd party components for common tasks IMO.

> Gogs is not even self-hosting gogs but hosted at github.

That's because github is awesome. That says more about github
than gogs IMO ;-)

> gogs.io does not even state which license it has ("Open Source It all at guithub"),

It says MIT at the bottom of the page. A link takes you directly to the
COPYING file in the github repo.

> 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.)

What's the "B" criteria?

I don't like gitlab's UI as much as github's, but I can't constructively
point the finger at what it is. But I'll get used to it just as I got used
to sending patches via email... ;-)

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

[David Craven]

> I don't like gitlab's UI as much as github's, but I can't constructively
> point the finger at what it is. But I'll get used to it just as I got used
> to sending patches via email... ;-)

I think that most of us have already learnt the current system. The main
point I think is decreasing entry barriers for potential contributors. Many
will likely already have experience using github, but are less likely to have
experience with gitlab. Even dough the differences are probably small,
why force potential contributors to change their way of doing things if
it isn't necessary?

If we do decide to use gitlab or gogs, I think we can have the discussions
that are happening on guix-devel and guix-bugs there. What about the
discussions that happen on guix-help? I'm not sure if we should encourage
questions to be posted as an issue or encourage users to ask on
stackoverflow. I like posting questions on github directly, but if the project
grows we could end up with more "beginner questions" with a "read the
manual" answer than other issues.

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

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 --]