discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Savannah bug tracker disabled?


From: Matt Rice
Subject: Re: Savannah bug tracker disabled?
Date: Tue, 5 Nov 2019 05:30:29 +0000

On Tue, Nov 5, 2019 at 3:20 AM Jordan Schidlowsky <address@hidden> wrote:
>
>
>
> Sent from my iPhone
>
> > On Nov 4, 2019, at 7:39 PM, Matt Rice <address@hidden> wrote:
> >
> > On Tue, Nov 5, 2019 at 12:59 AM Gregory Casamento
> > <address@hidden> wrote:
> >>
> >>
> >>
> >>> On Mon, Nov 4, 2019 at 1:36 PM Jordan Schidlowsky <address@hidden> wrote:
> >>>
> >>> Is everyone here forgetting git is not svn?  git is a DISTRIBUTED 
> >>> versioning system.  As in, when you use checkout a repo you have a copy 
> >>> of the ENTIRE repository.  Github is really just another remote for the 
> >>> repo.  It's absolutely TRIVIAL to setup a mirror on whatever other 
> >>> service you like (including hosting your own solution).
> >>
> >>
> >> No, I'm not forgetting.
> >>
> >>>
> >>> If people are really concerned about the bug/issue tracking being tied to 
> >>> github's platform, then just do in-repository tracking.  Pretty simple.  
> >>> If you wanna take advantage of the GitHub platform for pull requests and 
> >>> issue tracking then do it.  If you are concerned about ANY part of the 
> >>> project being tied to a service/hosting provider then just add some 
> >>> process to track those things in-repository as well...    (include the 
> >>> wiki and the website as well?)
> >>>
> >>> https://github.com/MichaelMure/git-bug  (GPL BTW)
> >>
> >>
> >> I like this because it means we can take our bug list with us.  I wish 
> >> there was a way I could export the bugs from Savannah and import them here.
> >
> > I kind of like this, What I suppose I would really like is if bug
> > reports had good support for markdown format, and you could integrate
> > markdown code blocks directly into the bug thread
> > and extract them as testcases for use in the testsuite.  I don't know
> > if there is anything like that out there, but seems like it could be
> > nice.
> >
> > Sorry kind of random...
>
>  I guess I really don’t get it...  Isn’t this exactly github?
>

No, not at all like github really.

Because git-bug stores bug reports in repository, i'm saying that you
could automatically extract tests from code blocks within bug reports
for `make check`.

The only real similarity is that both would support markdown, but it
doesn't support it in a way that
allows you to run programs which process the markdown in bug reports
programmatically and are relevant to the repository.

Once you close a bug in github it just goes into a list of closed
things, and doesn't form a basis from which you stop it from
regressing in the future.  The only correlation it has to the
repository is perhaps a line in the commit message referring to the
bug #id...

Bringing bugs into the repository allows for a much stronger correlation.

> >
> >
> >>>
> >>>
> >>> TBH most of this thread is FUD.  git itself solves almost all these 
> >>> problems.  IMHO, use GitHub as a remote for the repo (the advantages are 
> >>> clear).  If some don't like GitHub or have issues with it, mirror.  If 
> >>> there are concerns about vendor lock-in, then track (or additionally 
> >>> track) in-repository.
> >>
> >>
> >> I was simply trying to move things forward.  If people really want me to 
> >> open back up savannah's bug tracker I will do so, but I believe it's best 
> >> to use the one here as the main one and that was for older bugs.  No new 
> >> bugs should be opened there.
> >>>
> >>>
> >>>
> >>> On Nov 4, 2019, at 4:46 AM, Ivan Vučica <address@hidden> wrote:
> >>>
> >>> I’ll answer as if you are asking the question and not asking rhetorically.
> >>>
> >>> Whoever hosts the project takes over the responsibility for:
> >>>
> >>> - storing user credentials
> >>> - abuse management
> >>> - security and service upgrades
> >>> - data migration when moving from service A to service B
> >>> - possibly even GDPR and other privacy requests (data portability, right 
> >>> to be forgotten)
> >>> - backups AND restores
> >>> - service uptime and monitoring (remember, no SLO means 100% uptime which 
> >>> is a terrible impossible-to-reach target)
> >>> - administrative overhead and user support
> >>> - complaints when things aren’t going right
> >>> - deciding who gets administrative credentials to execute all of the above
> >>> - deciding how to finance all this ($5 droplet on digital ocean or 
> >>> something more?€
> >>> - technical planning for all the above
> >>>
> >>> They take this on even if they are not aware of it.
> >>>
> >>> I’m hosting my own stuff. Aside from development work, for three weeks a 
> >>> quarter hold a pager and/or respond to tickets in my professional life 
> >>> and/or shepherd automated or semiautomated software deployment processes. 
> >>> Something like GNUstep hosting would be less labor than that — but it’s 
> >>> still quite some stuff to be responsible for.
> >>>
> >>> This is even before we get into technical choices you should make and how 
> >>> long it takes to deploy them.
> >>>
> >>> apt-get install $LISTOFPACKAGES won’t cut it.
> >>>
> >>>> On Mon 4 Nov 2019 at 10:26, Umberto Cerrato <address@hidden> wrote:
> >>>>
> >>>> Why don’t you self host your project in your own website? Something like 
> >>>> a self hosted Savannah or similar (there are few around). Then you 
> >>>> could: modify the UI to make it more GitHub-like and user friendly and 
> >>>> leave some landing projects on GitHub, GitLab etc. that redirect to your 
> >>>> e.g. subdomain with hosted files and bug tracker etc.
> >>>>
> >>>> Hello there anyway…
> >>>
> >>> --
> >>> Sent from Gmail Mobile
> >>>
> >>>
> >>
> >>
> >> --
> >> Gregory Casamento
> >> GNUstep Lead Developer / OLC, Principal Consultant
> >> http://www.gnustep.org - http://heronsperch.blogspot.com
> >> http://ind.ie/phoenix/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]