Hi!
Just my two cents: I don't think that SlackBuilds on SBo are that
outdated. Most of the time they are a rather new version. I'm guilty
myself for not updating some of my SlackBuilds that often ;)
Like some others posted here, I think that Gitlab (or something like
that) would make updating
Le 21/01/2017 à 12:32, Andrzej Telszewski a écrit :
> I'm really having hard times finding major problems with SBo, both as a
> maintainer and user.
Same here. SBo obeys to the KISS principle pretty much like its
Slackware foundation.
Recently I was annoyed by VirtualBox lagging several versions
On 21/01/17 12:21, David Spencer wrote:
this is the first problem, as most of the times there aren't any pull
request but "hey, X has been updated to W.Y.Z, update it ASAP!"
I know you have had some bad experiences with pull requsts into your
unofficial -current repository.
But if we listen
2017-01-21 12:21 GMT+01:00 David Spencer :
>> this is the first problem, as most of the times there aren't any pull
>> request but "hey, X has been updated to W.Y.Z, update it ASAP!"
>
> I know you have had some bad experiences with pull requsts into your
>
> this is the first problem, as most of the times there aren't any pull
> request but "hey, X has been updated to W.Y.Z, update it ASAP!"
I know you have had some bad experiences with pull requsts into your
unofficial -current repository.
But if we listen to the idea behind Harald's suggestion,
On 21/01/17 11:56, Harald Achitz wrote:
ok, slowly, one more time
1) the one who is sending the pull request
2) the one who is applying the pull request
3) those who use the package in testing,
4) merging testing into stable at the time a package can be considered
as tested, eg due to positive
there are no pull request because of missing chances , high entry barriers
, ask the maintainer, and similar
I am talking about projects that reduced work for 1 persons, as mentioned,
and now I quit with this,
I gave you knowledge,f feel free to ignore or discuss it to death,
have a nice weekend
2017-01-21 11:56 GMT+01:00 Harald Achitz :
> ok, slowly, one more time
> 1) the one who is sending the pull request
this is the first problem, as most of the times there aren't any pull
request but "hey, X has been updated to W.Y.Z, update it ASAP!"
> 2) the one who is
On 21/01/17 11:56, Harald Achitz wrote:
ok, slowly, one more time
1) the one who is sending the pull request
2) the one who is applying the pull request
3) those who use the package in testing,
4) merging testing into stable at the time a package can be considered
as tested, eg due to positive
ok, slowly, one more time
1) the one who is sending the pull request
2) the one who is applying the pull request
3) those who use the package in testing,
4) merging testing into stable at the time a package can be considered as
tested, eg due to positive feedback on a issue tracer.
more quality
> maybe it's me but I still can't understand also from this answer who's
> gonna do the QA...
If it's the maintainer, why would they respond to a pull request if
they don't respond to email?
If it's anybody, how do we (the community) know they have done enough
tests, follow upstream mailing
2017-01-21 11:42 GMT+01:00 Harald Achitz :
> as mentioned in the earlier mail, for example
> stable , testing, pull requests into testing, who wants can test, if no
> problem reports, or some people say OK, (to be defined) it goes to stable.
> the QA happens twice, once
as mentioned in the earlier mail, for example
stable , testing, pull requests into testing, who wants can test, if no
problem reports, or some people say OK, (to be defined) it goes to stable.
the QA happens twice, once when apply the pull request,similar what is
already done today, so no more
On 21/01/17 08:21, Harald Achitz wrote:
Hi,
help is difficult,
the SBo rules are clear,
If you sent an updated version of a package, you need the OK of the
maintainer.
If you contact a maintainer, and there is no response, what than?
This is a barrier, unnecessary.
Git stable & testing, branch.
Hi,
help is difficult,
the SBo rules are clear,
If you sent an updated version of a package, you need the OK of the
maintainer.
If you contact a maintainer, and there is no response, what than?
This is a barrier, unnecessary.
Git stable & testing, branch.
pull requests to testing,
when some have
On 21/01/17 06:12, Erik Hanson wrote:
> On Fri, 20 Jan 2017 18:42:29 +1300
> Klaatu wrote:
>
>> I was under the impression that SlackBuilds.org mimicked Slackware
>> itself in update policy: release, and then it's primarily up to the
>> user to adapt the build scripts if
Il giorno Thu, 19 Jan 2017 12:46:46 -0500
"Full Name" ha scritto:
> Having said that, all too often maintainers do not update the
> software all that promptly. It is not uncommon to have Slackbuilds
> packages that are several releases behind what one can get from
>
I contacted the maintainer of the qt build, no reply.
This is not good.
This picks up the initial post. The "mail the maintainer"-policy might
not be efficient enough.
Maybe a request-file per maintainer in git could help
-the maintainer to keep track what has to be done
-the
Here my 2 cents
Here is a list of files changed from Qt 5.6.1 to 5.6.2
each of the files contain a list of bugs.
5.6.2 has been release in October, this is quite a while ago.
A update of Qt LTS is not about having the latest and greatest, it is about
updating a package with known bugs against a
On Fri, 20 Jan 2017 18:42:29 +1300
Klaatu wrote:
> I was under the impression that SlackBuilds.org mimicked Slackware
> itself in update policy: release, and then it's primarily up to the
> user to adapt the build scripts if further maintenance is required.
> That's why
On 20/01/17 08:18, x80 wrote:
I'll add my thoughts as amusement for the group here. As a happy user of
Slackware64 14.1 and a Linux user for almost 25 years when I access the
slackbuilds repo for a build script I expect it to work, period. The
last package I downloaded was the build script for
Le 19/01/2017 à 18:46, Full Name a écrit :
> Having said that, all too often maintainers do not update the
> software all that promptly. It is not uncommon to have Slackbuilds
> packages that are several releases behind what one can get from
> distributions like (shudder) Fedora or (shudder!)
> If SlackBuilds.org is going to follow -current, then maybe there ought
> to be a separate git branch for -current? That way I can pull in new
> buildscripts without updating old buildscripts out from under me.
I am _not_ following -current, nor am I going to.
-petar
>On 20/01/17 07:01, Ryan P.C. McQuen wrote:
>> On 1/19/17, Full Name wrote:
>>> As a long time user of Slackware, I am immensely grateful to the
>>> people who have volunteered (and continue to do so) their time and
>>> effort to maintain and update third-party code,
On 01/19/2017 09:42 PM, Klaatu wrote:
On 20/01/17 07:01, Ryan P.C. McQuen wrote:
On 1/19/17, Full Name wrote:
As a long time user of Slackware, I am immensely grateful to the people who
have volunteered (and continue to do so) their time and effort to maintain
On 20/01/17 07:01, Ryan P.C. McQuen wrote:
> On 1/19/17, Full Name wrote:
>> As a long time user of Slackware, I am immensely grateful to the people who
>> have volunteered (and continue to do so) their time and effort to maintain
>> and update third-party code, so
http://repology.org/
I’m going to have to level up on my maintaining :(
What I hate about tools like these, is for packages like nodejs, we
are shown as out-of-date, when in actuality we have the very latest
LTS version. You’d be crazy to run a non-LTS node server, but alas …
it is helpful for a
On 01/19/2017 07:01 PM, David Spencer wrote:
> Blimey. This is new ... and *very* scary
>
> http://repology.org/
>
> I'm going to have to level up on my maintaining :(
> -D.
>
>
I like to think they're doing me a favor and keeping track of my
packages for me. Beats the sbo.txt I keep in ~
Blimey. This is new ... and *very* scary
http://repology.org/
I'm going to have to level up on my maintaining :(
-D.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
I am currently guilty of not recently updating my builds, but will act
promptly if i receive a report.
With that being said, there are exceptions in which i will delay or skip an
update. My preference is to test each new release for at least 2 weeks for
stability and to watch bug reports before
On 1/19/17, Eric Pratt wrote:
> I know I'm definitely guilty of letting my slackbuilds slip for long
> periods of time. I'm trying to prevent that moving forward, but it's
> really mostly a matter of getting the time to do it and remembering to do
> it. So I like the
I know I'm definitely guilty of letting my slackbuilds slip for long
periods of time. I'm trying to prevent that moving forward, but it's
really mostly a matter of getting the time to do it and remembering to do
it. So I like the auto-updating idea. It would get many of us past the
remembering
On 19/01/17 19:45, David Spencer wrote:
As a radical idea, we could consider making some packages
auto-updating. I suspect lots of perl, python, haskell and ruby could
be completely automated. I bet everybody hates this idea :p
You bet ;-)
On the other hand, George from Salix made a very
A few constructive thoughts --
Many years ago the advice was that we should not always update our
SlackBuilds for simple version bumps, because it's easy to use
VERSION=. But I think times have changed, git makes the whole process
easier for the admins and we are always happy to see updates.
The
I think that slackware is easiers from ubuntu. That's my experience. Updates?
Slackware's more stable. Need additional software? Slackbuilds.org. Yes,
maintainers can don't update his software, but in 95% only VERSION variable
update is needed.
19 янв. 2017 г. 23:46 пользователь Full Name
On 1/19/17, Full Name wrote:
> As a long time user of Slackware, I am immensely grateful to the people who
> have volunteered (and continue to do so) their time and effort to maintain
> and update third-party code, so that the rest of us Slackware users can
>
36 matches
Mail list logo