What is the problem with ports PR reaction delays?
bapt at FreeBSD.org
Sun Jan 26 19:28:17 UTC 2014
On Sat, Jan 25, 2014 at 06:04:52PM -0800, Alfred Perlstein wrote:
> On 1/25/14 3:48 PM, Aryeh Friedman wrote:
> > On Sat, Jan 25, 2014 at 6:41 PM, Yuri <yuri at rawbw.com> wrote:
> >> On 01/25/2014 14:44, Aryeh Friedman wrote:
> >>> The key seems to be that no one has time to do the stuff they really want
> >>> to do (get new ports into the system)... to that end automating everything
> >>> that can be automated is sure help free up comitter time so they can look
> >>> at what is interesting
> >> Yes. I just can't imagine any generic port tests that can't be automated
> >> and coded into the script once and for good.
> >> Ideal system should be like github with the added automated testing
> >> between pull request submission and merge. It should either fail and notify
> >> the submitter, or succeed and notify the committers.
> > Git hup (or *ANY* remote service for that matter) is a no go IMO
> You just don't get it.
> Again, you just really, really, don't get it.
> You WANT a gateway to a remote service that the project does not have to
> Why? Because then we offload the problem to another org.
> The FreeBSD project should be about innovation in OS design, platform
> and software. Ops work is bunk and just slows us down.
> The more we can outsource the better we'll be. (and what if that
> service blows up? well we move on! it's simple!)
> Continuing to insist that we run the services ourselves it just wasting
> our limited resources. Not only that but we get emotionally attached to
> technologies that are old, dying and dead when off the shelf stuff works
> just fine.
Insourced or Outsource, or what ever once again the problem is to actually do
the stuff, setup, manage the migration and all of this is just about humans.
We can change easily if someone is deciding to actually do something, with
concrete proposition, and concrete actions.
It is easy to just say use github or what ever other cool and nice
service/tool/methodology. But that serves nothing if noone is willing to actually do
the job, really study what is going on behind the scene, what are the exhaustive
inpact of doing the change, what are the existing drawbacks how do we
handle them etc.
Once again the problem is not the tools, the problem is how many people are
actually really going through PR, study them (no automated tools can do that),
run exhaustive tests (that can be automated and we have tools for that) do
runtime test, most of the time this cannot be automated.
Please instead of always coming saying what we should do and how stupid we are
not doing that, come with concrete proposition and willing to drive the change.
FreeBSD is able to handle important changes, and accept that change pretty
nicely as long as someone is driving the change and proving what he propose is
As a matter of example, we now have pkgng, which was proposed and developped by
a non freebsd guy at the time (me) and still accepted. The project gave me my
We now have packages built on regular basis on completly new tools and new way
to build them and 100% automated.
We now have signed packages (how many people have been talking about it for years)
on a completely new tools and new way to do it, the projet has accepted those
changes because someone was willing to drive them.
So you want to improve how we handle Pr and get them committed in a faster way
great we really need someone to work on this and help improving the situation,
you want to improve by going in a totally more modern, efficient way along with
new tools etc? hey why not? come to talk with portmgr, bugmeister, clusteradm etc
come to explain us what you want to setup, how, we will tell you what are our
requirements (there are lots of things in the background that may be inpacted)
show us you want to drive that and that it is realistic.
You cannot do it yourself because $reason, find someone else that shares your
views and get him drive the project.
That is how things works.
You say debian is doing a better job? maybe, study what they do and come with
FYI I have done all that work for the package side, and I continue doing it.
studying debian, fedora, but also how things are done in other BSDs, Windows,
etc, and I'm trying to bring what I found the best of all of them without
breaking to much at one (that is why pkgng is right now doing only 60% of what I
have in mind).
Sorry I may sound a bit aggressive, but I'm a bit pissed of easy vague
propositions with nothing real behind, right now from what you say except
claiming you should do better I see nothing real based on facts, you even prove
you don't know how we work on PR, what tools are available. You just want to
promote the github way because you like it (great why not)
The only point you gave us is about the lack of documentation for those tools,
cool that a true point, will you help us on that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the freebsd-ports