subject:"What is the problem with ports PR reaction delays\?"

On Sat, Jan 25, 2014 at 11:59 AM, Matthew Seaman matt...@freebsd.orgwrote:

 On 25/01/2014 10:35, Big Lebowski wrote:
  Thus, are you volunteering for this role?  It's not my call, but if you
   really want to do clean out and triage the all PRs on an ongoing
 basis,
   my guess is that would be very welcome and we'd figure out a way to
 set
   that up.  It would definitely help, especially for those maintainer
 that
   approve patches but the PRs never get opened (or set to a better
 state
   than open).

  If I wouldnt care about FreeBSD and ports state and I wouldnt want to
 help
  with that, I would have not wrote this message in first place. Yes, I
 would
  love to help.

 There are a lot of people who would love to help with FreeBSD, and there
 is a lot of help that FreeBSD needs.  The problem is that anyone
 volunteering probably only has a limited amount of time they can donate
 to the project, and there exists at the moment no simple mechanism for
 dividing up the workload into small, easily digestible chunks.

 Take the case of PR triage, often cited as a suitable track for people
 to start getting involved.  Say we get about 300 new PRs in a week.
 What we need is 20--50 people looking at 6--15 PRs a week, rather than
 2--5 people trying to look at 60--150 PRs a week.  Trouble is, the first
 few people to volunteer will find themselves drinking from the PR
 firehose, and will probably give up long before enough additional people
 can be drummed up to share the load.


Does it have to be all-or-nothing situation, where we can do something only
if we have 20-50 people looking at 6-15 PR's a week, and we cant do
anything if we dont? Cant we start with 2-3 people (3 people so far
volunteered to do so, and I belive a 'call to arms' via this
list/announcements/bsdnow.tv/reddit would result in may others willing to
help) doing as much as they can?

Also, what about some kind of 'junior commiter' role, where solid port
maintainers get rights to commit to their ports only? If that would be
doable, we could offload a lot of work from current commiters to work on
other things.

B.



 Cheers,

 Matthew

 --
 Dr Matthew J Seaman MA, D.Phil.
 PGP: http://www.infracaninophile.co.uk/pgpkey



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:

 Hello,


 On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

 On 1/25/14 3:48 PM, Aryeh Friedman wrote:

 On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
 handle.

 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.


 I've read all 60 or so messages in this thread and there really are two
 related but distinct issues here.

 The thread title is What is the problem with ports PR reaction delays?.
 This has meandered into a philosophical debate about who knows what and who
 knows squat about version control systems, whether we need to maintain
 certain requirements, testing ports, etc.

 I like the KISS approach myself. This can be boiled down to those two
 issues, one of which is a symptom of the other. Arguing and debating over a
 long term solution to the OP's question does nothing to solve the problem
 in the short to intermediate term. There are 1680 current ports related
 PR's at this moment.

 As we all know, the committers are volunteers, mostly with real jobs and
 real lives and they obviously cannot keep up with the current load. The
 short to medium term solution for that is more committers. I'll add my name
 to the list of those who are willing to step in and help to clean up the
 mess. I'm certain that if a request went out, there would be many who are
 more qualified than I.

 At the same time, a group of interested individuals should offer input to
 the folks who already are looking at changing the bug reporting system away
 from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
 Doing it in one fell swoop might make sense. It's ripping off the bandaid
 but I'd rather do it only once myself.

 What does *not* make sense is a new port for what might be a very useful
 tool waiting since September for someone to look at it. Arguing over git
 and subversion et alia does nothing to fix that. As they say on the ESPN
 NFL pregame show, C'mon man!.


I can't agree more. I can see, understand and accept reasons why we cant
move from SVN to GitHub/Git and I certainly dont think that it would be
solution to current problems. It seems like this is not neccessary, it wont
happen, so I think we can end that discussion here. However, we do have all
the tools to automate this process, so I really dont understand why not to
do this, especially it is perfectly doable with SVN, Redports are already
doing so, and there are people willing to work on it.

And when it comes to number of ports commiters, that seems to be too low to
handle current, manual process, why exactly this number is so low? I would
think there is not enough skilled people, but given Martin mentioned there
are sloppy commiters not doing their work exactly right, this doesnt seem
to be the case - what then? Could that process be more formalized,
transparent, so people interested could have a path to follow and the
ability to become commiters to support the ports team? I've mentioned the
idea of 'junior commiters' in my previous message, perhaps that's something
we could talk about?

One another thing I would do, is to handle the problem of amount of the
work that needs to be done, that tends to be a huge demotivation for people
to do work - when there's over 1600 PR's waiting to be handled, it
seriously harm the hope for getting the work done (emptying the queue) and
that's a stopper. Perhaps it would be possible to make a cut off for PR's
opened more than X weeks/months/years ago, their submitters arent answering
to emails, their emails are dead, neither submitters nor other users are
asking for, send emails to submitters and ports list

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Gary J. Hayers


On 26/01/2014 13:06, Big Lebowski wrote:

On Sat, Jan 25, 2014 at 11:59 AM, Matthew Seaman matt...@freebsd.orgwrote:
Does it have to be all-or-nothing situation, where we can do something only
if we have 20-50 people looking at 6-15 PR's a week, and we cant do
anything if we dont? Cant we start with 2-3 people (3 people so far
volunteered to do so, and I belive a 'call to arms' via this
list/announcements/bsdnow.tv/reddit would result in may others willing to
help) doing as much as they can?


I get the feeling more people would volunteer if it meant clearing the 
backlog of PRs. I have a lot of spare time so I could go through a lot 
of PRs.



Also, what about some kind of 'junior commiter' role, where solid port
maintainers get rights to commit to their ports only? If that would be
doable, we could offload a lot of work from current commiters to work on
other things.


Suspect this would work, however, the more committers the less the 
quality of work?


--

Regards,
Gary J. Hayers
g...@hayers.org

PGP Signature
http://www.hayers.org/pgp
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sun, Jan 26, 2014 at 2:29 PM, Gary J. Hayers g...@hayers.org wrote:

 On 26/01/2014 13:06, Big Lebowski wrote:

 On Sat, Jan 25, 2014 at 11:59 AM, Matthew Seaman matt...@freebsd.org
 wrote:
 Does it have to be all-or-nothing situation, where we can do something
 only
 if we have 20-50 people looking at 6-15 PR's a week, and we cant do
 anything if we dont? Cant we start with 2-3 people (3 people so far
 volunteered to do so, and I belive a 'call to arms' via this
 list/announcements/bsdnow.tv/reddit would result in may others willing to
 help) doing as much as they can?


 I get the feeling more people would volunteer if it meant clearing the
 backlog of PRs. I have a lot of spare time so I could go through a lot of
 PRs.


  Also, what about some kind of 'junior commiter' role, where solid port
 maintainers get rights to commit to their ports only? If that would be
 doable, we could offload a lot of work from current commiters to work on
 other things.


 Suspect this would work, however, the more committers the less the quality
 of work?


Is there any evidence to support that argument? Or is it just a fear of
that? At any point if that happens, then this can be revoked, the selection
can be tighter, things can be adjusted, nothing is written in stone. Also,
people were mentioning existing commiters to be sloppy and problematic,
we've months of waiting for PR's to be taken care of, and there are still
ports accepted that dont work at all - is that this work quality we're so
troubled for?

B.




 --

 Regards,
 Gary J. Hayers
 g...@hayers.org

 PGP Signature
 http://www.hayers.org/pgp

 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Gary J. Hayers




On 26/01/2014 13:32, Big Lebowski wrote:

On Sun, Jan 26, 2014 at 2:29 PM, Gary J. Hayers g...@hayers.org wrote:

Suspect this would work, however, the more committers the less the quality
of work?

Is there any evidence to support that argument? Or is it just a fear of
that? At any point if that happens, then this can be revoked, the selection
can be tighter, things can be adjusted, nothing is written in stone. Also,
people were mentioning existing commiters to be sloppy and problematic,
we've months of waiting for PR's to be taken care of, and there are still
ports accepted that dont work at all - is that this work quality we're so
troubled for?

B.


That's a fear admittedly, but your solution would take care of that, 
would that also mean a bigger portmgr team too?


--

Regards,
Gary J. Hayers
g...@hayers.org

PGP Signature
http://www.hayers.org/pgp
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sun, Jan 26, 2014 at 2:35 PM, Gary J. Hayers g...@hayers.org wrote:



 On 26/01/2014 13:32, Big Lebowski wrote:

 On Sun, Jan 26, 2014 at 2:29 PM, Gary J. Hayers g...@hayers.org wrote:

 Suspect this would work, however, the more committers the less the
 quality
 of work?

 Is there any evidence to support that argument? Or is it just a fear of
 that? At any point if that happens, then this can be revoked, the
 selection
 can be tighter, things can be adjusted, nothing is written in stone. Also,
 people were mentioning existing commiters to be sloppy and problematic,
 we've months of waiting for PR's to be taken care of, and there are still
 ports accepted that dont work at all - is that this work quality we're so
 troubled for?

 B.


 That's a fear admittedly, but your solution would take care of that, would
 that also mean a bigger portmgr team too?


At no point I've suggested anything regarding portmgr team, and I am not in
position to judge needs of any changes in that place. It seems however,
that with the portsmgr-lurker project they're handling their situation in a
good way.

B.



 --

 Regards,
 Gary J. Hayers
 g...@hayers.org

 PGP Signature
 http://www.hayers.org/pgp
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Gary J. Hayers


On 26/01/2014 14:05, Big Lebowski wrote:

On Sun, Jan 26, 2014 at 2:35 PM, Gary J. Hayers g...@hayers.org wrote:
At no point I've suggested anything regarding portmgr team, and I am not in
position to judge needs of any changes in that place. It seems however,
that with the portsmgr-lurker project they're handling their situation in a
good way.

B.


Agreed

--

Regards,
Gary J. Hayers
g...@hayers.org

PGP Signature
http://www.hayers.org/pgp
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in 
mailto:j...@ohlste.in wrote:


Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@rawbw.com
mailto:y...@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
handle.

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.


I've read all 60 or so messages in this thread and there really
are two related but distinct issues here.

The thread title is What is the problem with ports PR reaction
delays?. This has meandered into a philosophical debate about who
knows what and who knows squat about version control systems,
whether we need to maintain certain requirements, testing ports, etc.

I like the KISS approach myself. This can be boiled down to those
two issues, one of which is a symptom of the other. Arguing and
debating over a long term solution to the OP's question does
nothing to solve the problem in the short to intermediate term.
There are 1680 current ports related PR's at this moment.

As we all know, the committers are volunteers, mostly with real
jobs and real lives and they obviously cannot keep up with the
current load. The short to medium term solution for that is more
committers. I'll add my name to the list of those who are willing
to step in and help to clean up the mess. I'm certain that if a
request went out, there would be many who are more qualified than I.

At the same time, a group of interested individuals should offer
input to the folks who already are looking at changing the bug
reporting system away from gnats -
https://wiki.freebsd.org/Bugtracking/BugRelocationPlan. Doing it
in one fell swoop might make sense. It's ripping off the bandaid
but I'd rather do it only once myself.

What does *not* make sense is a new port for what might be a very
useful tool waiting since September for someone to look at it.
Arguing over git and subversion et alia does nothing to fix that.
As they say on the ESPN NFL pregame show, C'mon man!.


I can't agree more. I can see, understand and accept reasons why we 
cant move from SVN to GitHub/Git and I certainly dont think that it 
would be solution to current problems. It seems like this is not 
neccessary, it wont happen, so I think we can end that discussion 
here. However, we do have all the tools to automate this process, so I 
really dont understand why not to do this, especially it is perfectly 
doable with SVN, Redports are already doing so, and there are people 
willing to work on it.




Thanks Big Lebowski spankthes...@gmail.com!

I'm not sure if taking your word for it will be the be all and end all 
of progress on this issue.  I do have hope, after all as Max Plancksaid:


A new scientific truth does not triumph by convincing its opponents and 
making them see the light, but rather because its opponents eventually 
die, and a new generation grows up that is familiar with it.


I just have my fingers cross that we are not so insular, so heels dug

Re: What is the problem with ports PR reaction delays?

just do us a favor and do not assume newer means better...


On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein alf...@freebsd.orgwrote:

  On 1/26/14 5:25 AM, Big Lebowski wrote:




 On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:

 Hello,


 On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

 On 1/25/14 3:48 PM, Aryeh Friedman wrote:

 On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
 handle.

 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.


  I've read all 60 or so messages in this thread and there really are two
 related but distinct issues here.

 The thread title is What is the problem with ports PR reaction delays?.
 This has meandered into a philosophical debate about who knows what and who
 knows squat about version control systems, whether we need to maintain
 certain requirements, testing ports, etc.

 I like the KISS approach myself. This can be boiled down to those two
 issues, one of which is a symptom of the other. Arguing and debating over a
 long term solution to the OP's question does nothing to solve the problem
 in the short to intermediate term. There are 1680 current ports related
 PR's at this moment.

 As we all know, the committers are volunteers, mostly with real jobs and
 real lives and they obviously cannot keep up with the current load. The
 short to medium term solution for that is more committers. I'll add my name
 to the list of those who are willing to step in and help to clean up the
 mess. I'm certain that if a request went out, there would be many who are
 more qualified than I.

 At the same time, a group of interested individuals should offer input to
 the folks who already are looking at changing the bug reporting system away
 from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
 Doing it in one fell swoop might make sense. It's ripping off the bandaid
 but I'd rather do it only once myself.

 What does *not* make sense is a new port for what might be a very useful
 tool waiting since September for someone to look at it. Arguing over git
 and subversion et alia does nothing to fix that. As they say on the ESPN
 NFL pregame show, C'mon man!.


  I can't agree more. I can see, understand and accept reasons why we cant
 move from SVN to GitHub/Git and I certainly dont think that it would be
 solution to current problems. It seems like this is not neccessary, it wont
 happen, so I think we can end that discussion here. However, we do have all
 the tools to automate this process, so I really dont understand why not to
 do this, especially it is perfectly doable with SVN, Redports are already
 doing so, and there are people willing to work on it.


 Thanks Big Lebowski spankthes...@gmail.com spankthes...@gmail.com!

 I'm not sure if taking your word for it will be the be all and end all of
 progress on this issue.  I do have hope, after all as Max Planck said:

 A new scientific truth does not triumph by convincing its opponents and
 making them see the light, but rather because its opponents eventually die,
 and a new generation grows up that is familiar with it.

 I just have my fingers cross that we are not so insular, so heels dug deep
 in the dirt, and so curmudgeonly that we drive away anyone interested in
 new technology.

 I mean, if we're all so firm in our beliefs there are dozens of other open
 source projects that encourage new things that people will flock to.


 -Alfred





-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any

Re: What is the problem with ports PR reaction delays?


On 1/26/14 10:21 AM, Aryeh Friedman wrote:

just do us a favor and do not assume newer means better...


I've been using newer almost exclusively for the past several years and 
it is better.


Open your eyes, people have moved on.


-Alfred





On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein alf...@freebsd.orgwrote:


  On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:


Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:


On 1/25/14 3:48 PM, Aryeh Friedman wrote:


On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
handle.

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.


  I've read all 60 or so messages in this thread and there really are two
related but distinct issues here.

The thread title is What is the problem with ports PR reaction delays?.
This has meandered into a philosophical debate about who knows what and who
knows squat about version control systems, whether we need to maintain
certain requirements, testing ports, etc.

I like the KISS approach myself. This can be boiled down to those two
issues, one of which is a symptom of the other. Arguing and debating over a
long term solution to the OP's question does nothing to solve the problem
in the short to intermediate term. There are 1680 current ports related
PR's at this moment.

As we all know, the committers are volunteers, mostly with real jobs and
real lives and they obviously cannot keep up with the current load. The
short to medium term solution for that is more committers. I'll add my name
to the list of those who are willing to step in and help to clean up the
mess. I'm certain that if a request went out, there would be many who are
more qualified than I.

At the same time, a group of interested individuals should offer input to
the folks who already are looking at changing the bug reporting system away
from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
Doing it in one fell swoop might make sense. It's ripping off the bandaid
but I'd rather do it only once myself.

What does *not* make sense is a new port for what might be a very useful
tool waiting since September for someone to look at it. Arguing over git
and subversion et alia does nothing to fix that. As they say on the ESPN
NFL pregame show, C'mon man!.


  I can't agree more. I can see, understand and accept reasons why we cant
move from SVN to GitHub/Git and I certainly dont think that it would be
solution to current problems. It seems like this is not neccessary, it wont
happen, so I think we can end that discussion here. However, we do have all
the tools to automate this process, so I really dont understand why not to
do this, especially it is perfectly doable with SVN, Redports are already
doing so, and there are people willing to work on it.


Thanks Big Lebowski spankthes...@gmail.com spankthes...@gmail.com!

I'm not sure if taking your word for it will be the be all and end all of
progress on this issue.  I do have hope, after all as Max Planck said:

A new scientific truth does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually die,
and a new generation grows up that is familiar with it.

I just have my fingers cross that we are not so insular, so heels dug deep
in the dirt, and so curmudgeonly that we drive away anyone interested in
new technology.

I mean, if we're all so firm in our beliefs there are dozens of other open
source projects that encourage new things that people will flock to.


-Alfred







___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Matthew Seaman

On 26/01/2014 13:06, Big Lebowski wrote:
 Does it have to be all-or-nothing situation, where we can do something
 only if we have 20-50 people looking at 6-15 PR's a week, and we cant do
 anything if we dont? Cant we start with 2-3 people (3 people so far
 volunteered to do so, and I belive a 'call to arms' via this
 list/announcements/bsdnow.tv/reddit http://bsdnow.tv/reddit would
 result in may others willing to help) doing as much as they can?
 

It doesn't have to be all-or-nothing, but that is the way it tends to
end up.

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: What is the problem with ports PR reaction delays?

If it is so new then why when I looked into git and git hub for the first
time about 2 years ago it didn't have a *SINGLE* feature that aegis didn't
have in the mid-90's... all it is a bunch or pretty pictures to make those
who are addicted to newness be able to claim they are actually making
progress with their newness when in fact they are reinvinting the wheel
for the 15th time


On Sun, Jan 26, 2014 at 1:26 PM, Alfred Perlstein alf...@freebsd.orgwrote:

 On 1/26/14 10:21 AM, Aryeh Friedman wrote:

 just do us a favor and do not assume newer means better...


 I've been using newer almost exclusively for the past several years and it
 is better.

 Open your eyes, people have moved on.


 -Alfred




 On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein alf...@freebsd.org
 wrote:

On 1/26/14 5:25 AM, Big Lebowski wrote:




 On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:

  Hello,


 On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

  On 1/25/14 3:48 PM, Aryeh Friedman wrote:

  On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
 handle.

 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.

I've read all 60 or so messages in this thread and there really are
 two
 related but distinct issues here.

 The thread title is What is the problem with ports PR reaction
 delays?.
 This has meandered into a philosophical debate about who knows what and
 who
 knows squat about version control systems, whether we need to maintain
 certain requirements, testing ports, etc.

 I like the KISS approach myself. This can be boiled down to those two
 issues, one of which is a symptom of the other. Arguing and debating
 over a
 long term solution to the OP's question does nothing to solve the
 problem
 in the short to intermediate term. There are 1680 current ports related
 PR's at this moment.

 As we all know, the committers are volunteers, mostly with real jobs and
 real lives and they obviously cannot keep up with the current load. The
 short to medium term solution for that is more committers. I'll add my
 name
 to the list of those who are willing to step in and help to clean up the
 mess. I'm certain that if a request went out, there would be many who
 are
 more qualified than I.

 At the same time, a group of interested individuals should offer input
 to
 the folks who already are looking at changing the bug reporting system
 away
 from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
 Doing it in one fell swoop might make sense. It's ripping off the
 bandaid
 but I'd rather do it only once myself.

 What does *not* make sense is a new port for what might be a very useful
 tool waiting since September for someone to look at it. Arguing over git
 and subversion et alia does nothing to fix that. As they say on the ESPN
 NFL pregame show, C'mon man!.


   I can't agree more. I can see, understand and accept reasons why we
 cant
 move from SVN to GitHub/Git and I certainly dont think that it would be
 solution to current problems. It seems like this is not neccessary, it
 wont
 happen, so I think we can end that discussion here. However, we do have
 all
 the tools to automate this process, so I really dont understand why not
 to
 do this, especially it is perfectly doable with SVN, Redports are already
 doing so, and there are people willing to work on it.


 Thanks Big Lebowski spankthes...@gmail.com spankthes...@gmail.com!


 I'm not sure if taking your word for it will be the be all and end all of
 progress on this issue.  I do have hope, after all as Max Planck said:

 A new scientific truth does not triumph by convincing its opponents and
 making them see

Re: What is the problem with ports PR reaction delays?

Forgot to mention and aegis in almost every case implements the very same
features in a much smoother way (no stupid http bs or anything)


On Sun, Jan 26, 2014 at 1:31 PM, Aryeh Friedman aryeh.fried...@gmail.comwrote:

 If it is so new then why when I looked into git and git hub for the first
 time about 2 years ago it didn't have a *SINGLE* feature that aegis didn't
 have in the mid-90's... all it is a bunch or pretty pictures to make those
 who are addicted to newness be able to claim they are actually making
 progress with their newness when in fact they are reinvinting the wheel
 for the 15th time


 On Sun, Jan 26, 2014 at 1:26 PM, Alfred Perlstein alf...@freebsd.orgwrote:

 On 1/26/14 10:21 AM, Aryeh Friedman wrote:

 just do us a favor and do not assume newer means better...


 I've been using newer almost exclusively for the past several years and
 it is better.

 Open your eyes, people have moved on.


 -Alfred




 On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein alf...@freebsd.org
 wrote:

On 1/26/14 5:25 AM, Big Lebowski wrote:




 On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:

  Hello,


 On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

  On 1/25/14 3:48 PM, Aryeh Friedman wrote:

  On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
 handle.

 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.

I've read all 60 or so messages in this thread and there really
 are two
 related but distinct issues here.

 The thread title is What is the problem with ports PR reaction
 delays?.
 This has meandered into a philosophical debate about who knows what
 and who
 knows squat about version control systems, whether we need to maintain
 certain requirements, testing ports, etc.

 I like the KISS approach myself. This can be boiled down to those two
 issues, one of which is a symptom of the other. Arguing and debating
 over a
 long term solution to the OP's question does nothing to solve the
 problem
 in the short to intermediate term. There are 1680 current ports related
 PR's at this moment.

 As we all know, the committers are volunteers, mostly with real jobs
 and
 real lives and they obviously cannot keep up with the current load. The
 short to medium term solution for that is more committers. I'll add my
 name
 to the list of those who are willing to step in and help to clean up
 the
 mess. I'm certain that if a request went out, there would be many who
 are
 more qualified than I.

 At the same time, a group of interested individuals should offer input
 to
 the folks who already are looking at changing the bug reporting system
 away
 from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
 Doing it in one fell swoop might make sense. It's ripping off the
 bandaid
 but I'd rather do it only once myself.

 What does *not* make sense is a new port for what might be a very
 useful
 tool waiting since September for someone to look at it. Arguing over
 git
 and subversion et alia does nothing to fix that. As they say on the
 ESPN
 NFL pregame show, C'mon man!.


   I can't agree more. I can see, understand and accept reasons why we
 cant
 move from SVN to GitHub/Git and I certainly dont think that it would be
 solution to current problems. It seems like this is not neccessary, it
 wont
 happen, so I think we can end that discussion here. However, we do have
 all
 the tools to automate this process, so I really dont understand why not
 to
 do this, especially it is perfectly doable with SVN, Redports are
 already
 doing so, and there are people willing to work on it.


 Thanks Big Lebowski spankthes...@gmail.com spankthes...@gmail.com

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Baptiste Daroussin

On Sat, Jan 25, 2014 at 06:01:16PM -0800, Alfred Perlstein wrote:
 On 1/25/14 4:05 PM, Yuri wrote:
  On 01/25/2014 15:48, Aryeh Friedman wrote:
  Git hup (or*ANY*  remote service for that matter) is a no go IMO
 
  But both Debian and Fedora do this with automated remote testing, and 
  they don't seem to complain.
  How is our ports different in this respect?
 
 I don't get this either.
 

Because what they do is more complicated than that and they have way more people
dedicated to review, btw Fedora cannot be compared given they have way less
packages than we have but even if you do compare, then you will discover that
the automated tasks are about the same has what we have.

Concerning debian, the human review is also the bottleneck as for us, they have
just way more people working on packages. So more people to review things.

regards,
Bapt


pgpHYJOSiwpKX.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Baptiste Daroussin

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 y...@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 
 handle.
 
 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
working.

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

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

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?

regards,
Bapt



pgpPOm_IM5RtP.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?


On 1/26/14 10:32 AM, Aryeh Friedman wrote:
Forgot to mention and aegis in almost every case implements the very 
same features in a much smoother way (no stupid http bs or anything)




If aegis is so much better then we should use it.  Or everyone should 
use it... but why isn't everyone using it?


Can you explain?

Seriously, if it's so much better then please do tell!

-Alfred






On Sun, Jan 26, 2014 at 1:31 PM, Aryeh Friedman 
aryeh.fried...@gmail.com mailto:aryeh.fried...@gmail.com wrote:


If it is so new then why when I looked into git and git hub for
the first time about 2 years ago it didn't have a *SINGLE* feature
that aegis didn't have in the mid-90's... all it is a bunch or
pretty pictures to make those who are addicted to newness be able
to claim they are actually making progress with their newness
when in fact they are reinvinting the wheel for the 15th time


On Sun, Jan 26, 2014 at 1:26 PM, Alfred Perlstein
alf...@freebsd.org mailto:alf...@freebsd.org wrote:

On 1/26/14 10:21 AM, Aryeh Friedman wrote:

just do us a favor and do not assume newer means better...


I've been using newer almost exclusively for the past several
years and it is better.

Open your eyes, people have moved on.


-Alfred




On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein
alf...@freebsd.org mailto:alf...@freebsd.orgwrote:

  On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein
j...@ohlste.in mailto:j...@ohlste.in wrote:

Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri
y...@rawbw.com mailto:y...@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
handle.

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.

  I've read all 60 or so messages in this thread
and there really are two
related but distinct issues here.

The thread title is What is the problem with
ports PR reaction delays?.
This has meandered

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Pawel Biernacki

On 26 January 2014 18:34, Big Lebowski spankthes...@gmail.com wrote:

 -- Forwarded message --
 From: Big Lebowski spankthes...@gmail.com
 Date: Sat, Jan 25, 2014 at 12:30 AM
 Subject: What is the problem with ports PR reaction delays?
 To: freebsd-ports freebsd-ports@freebsd.org

 Hi everyone,

 I wanted to ask about the growing time of reaction to ports PR's - what is 
 the problem? It seems to me, as a ports contributor, that this time is only 
 growing, not shrinking, and there's no formal/automated procedures that would 
 help in managing the issue.

 Today I found myself fighting with ezjail only to discover it has issues 
 working on FreeBSD 10.0-R. Great, I thought, there must be something else, so 
 I went to make the research. It appears there isnt much more, and the 
 alternatives are qjail that seems to be quite dated and zjails, that's not in 
 ports. Not long after looking into zjails, what seems to be a great tool, I 
 found its port submission sits there since... September 2013. Now, given the 
 fact the Docker is on mouth of everyone, and containers are getting a lot of 
 attention, FreeBSD looks really bad with no tools to manage such great 
 technology like Jails, especially when ezjail, unofficial industry standard 
 to manage jails, is now broken and zjails waits to be accepted (or even 
 rejected) for so much time.

 What is the problem? Isnt there enought commiters? Isnt there a automated PR 
 handling procedure reminding commiters with relevant access about such 
 submissions? Can we help? I hope to spark some discussion.

Maybe it's time to look at how other projects with comparable amount
of contributed software manage to do it efficiently? How is that the
Debian folks are able to keep nearly 50k packages in four stages
(unstable, testing, stable, oldstable) not to mention branches like
Hurd or kFreeBSD? Do they just have more committers or maybe it's a
matter of involvement? Why? ports/svnadmin/conf/access shows 179
committers but how many of them is actually active? If they are no
longer interested, do not have time or anything else maybe you should
take the commit bit from them, not to make a false impression on
amount of people involved? Just give a chance to another person who
has time and wants to spend it working for the project - so for all of
us. IMO it's better than deceiving yourself that there's nothing you
can do about the long PRs queue, because you don't want to force
others to do anything. We saw several volunteers here, let them act.

-- 
One of God's own prototypes. A high-powered mutant of some kind never
even considered for mass production. Too weird to live, and too rare to die.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Fernando Apesteguía

On Sun, Jan 26, 2014 at 10:32 PM, Pawel Biernacki pawel.bierna...@gmail.com
 wrote:

 On 26 January 2014 18:34, Big Lebowski spankthes...@gmail.com wrote:

  -- Forwarded message --
  From: Big Lebowski spankthes...@gmail.com
  Date: Sat, Jan 25, 2014 at 12:30 AM
  Subject: What is the problem with ports PR reaction delays?
  To: freebsd-ports freebsd-ports@freebsd.org

  Hi everyone,

  I wanted to ask about the growing time of reaction to ports PR's - what
 is the problem? It seems to me, as a ports contributor, that this time is
 only growing, not shrinking, and there's no formal/automated procedures
 that would help in managing the issue.

  Today I found myself fighting with ezjail only to discover it has issues
 working on FreeBSD 10.0-R. Great, I thought, there must be something else,
 so I went to make the research. It appears there isnt much more, and the
 alternatives are qjail that seems to be quite dated and zjails, that's not
 in ports. Not long after looking into zjails, what seems to be a great
 tool, I found its port submission sits there since... September 2013. Now,
 given the fact the Docker is on mouth of everyone, and containers are
 getting a lot of attention, FreeBSD looks really bad with no tools to
 manage such great technology like Jails, especially when ezjail, unofficial
 industry standard to manage jails, is now broken and zjails waits to be
 accepted (or even rejected) for so much time.

  What is the problem? Isnt there enought commiters? Isnt there a
 automated PR handling procedure reminding commiters with relevant access
 about such submissions? Can we help? I hope to spark some discussion.

 Maybe it's time to look at how other projects with comparable amount
 of contributed software manage to do it efficiently? How is that the
 Debian folks are able to keep nearly 50k packages in four stages
 (unstable, testing, stable, oldstable) not to mention branches like
 Hurd or kFreeBSD? Do they just have more committers or maybe it's a
 matter of involvement? Why? ports/svnadmin/conf/access shows 179
 committers but how many of them is actually active? If they are no
 longer interested, do not have time or anything else maybe you should
 take the commit bit from them, not to make a false impression on
 amount of people involved? Just give a chance to another person who
 has time and wants to spend it working for the project - so for all of
 us. IMO it's better than deceiving yourself that there's nothing you
 can do about the long PRs queue, because you don't want to force
 others to do anything. We saw several volunteers here, let them act.

As a porter and maintainer, I fully agree about the delay in the processing
of PRs lately.

However, I wouldn't like to add more speculation. Can we put some numbers
to some of the questions asked above? (rate of incoming PR's, rate of
processed PRs, commiters activity, etc) Anybody from the Ports Management
Team is able to do it?

Once we put some figures to that questions, we can take an action, but it
would be unwise to do anything without knowing what the real problem is.

Regards

 --
 One of God's own prototypes. A high-powered mutant of some kind never
 even considered for mass production. Too weird to live, and too rare to
 die.
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-26 Thread Yuri


On 01/25/2014 11:38, Baptiste Daroussin wrote:

We just recovered from cvs-svn switch I think noone at all is willing to do the
job again.

Git has lots of drawbacks and if badly handled with all the above, it will be a
real nightmare.

and That is said from someone who likes git (except that the UI can get
overcomplicated)


Git has some features that aren't in svn, and also svn has some features 
that aren't in fit, though to the lesser extent. There is no reason why 
enough important missing features can't be added to both systems over 
time so that seamless back and forth data migration would be possible. 
Because they basically do the same thing.


Yuri
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

)



 If aegis is so much better then we should use it.  Or everyone should use
 it... but why isn't everyone using it?


Simple reason Peter Miller (the author of aegis/cook) for whatever reason
*NEVER* tried to market his stuff while GIT made a specific effort of
attempting to get outside users.   Peter (like most FOSS authors) wrote it
first and formost for himself and never say any need for others to use it
per se.   It would take too long to summarize all the differences (I have
already stated the major ones in the thread though).  If your really
interested take a look at the material at aegis.sf.net.


 Can you explain?

 Seriously, if it's so much better then please do tell!


The #1 reason (above all else IMO) is it doesn't rely (directly or
indirectly) on any third party for it's basic operation (which github does
unless the foundation wanted to duplicate which is a waste of time).  The
other main reason it works with existing tools where from what you describe
GitHub requires you install something (by working I mean you can look at
the baseline without any special tools)

Finally since your addicted to newness you will not get the most important
difference aegis has been in production for over 20 years where git hub 5
or 6?
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/26/14, 6:43 PM, Aryeh Friedman wrote:

)



If aegis is so much better then we should use it.  Or everyone should use
it... but why isn't everyone using it?


Simple reason Peter Miller (the author of aegis/cook) for whatever reason
*NEVER* tried to market his stuff while GIT made a specific effort of
attempting to get outside users.   Peter (like most FOSS authors) wrote it
first and formost for himself and never say any need for others to use it
per se.   It would take too long to summarize all the differences (I have
already stated the major ones in the thread though).  If your really
interested take a look at the material at aegis.sf.net.



Can you explain?

Seriously, if it's so much better then please do tell!


The #1 reason (above all else IMO) is it doesn't rely (directly or
indirectly) on any third party for it's basic operation (which github does
unless the foundation wanted to duplicate which is a waste of time).  The
other main reason it works with existing tools where from what you describe
GitHub requires you install something (by working I mean you can look at
the baseline without any special tools)

Finally since your addicted to newness you will not get the most important
difference aegis has been in production for over 20 years where git hub 5
or 6?
I'm not addicted to newness.  I think you just hate anything that is 
popular and you're butthurt that something that's may have been ahead of 
it's time was missed out on.  This is no reason to dig your heels in and 
complain as that accomplishes nothing.


What I am interested in is:

1) leveraging the hordes of people that can submit changes to the 
project because they know git.
2) leveraging the existing tooling that's available for FREE!!! for us 
to use. (instead of rewriting wheels).
3) reducing the overhead of contribution to our project by using 
existing solutions and not requiring accounts to be made.


So what would using this aegis system buy us?

1) Supposedly DVCS.

Now that is interesting!!!

In my list there is no mention of DVCS!  There is just the resulting 
benefits that Aegis doesn't have.


Aegis
1) doesn't have hordes of people that know how to use it.
2) doesn't have a free hosting solution for it which provides tooling we 
need for free.



It's not about NEW THINGS, although NEW THINGS tend to lead to better 
systems... it's more about leveraging users and existing facilities.


Anyhow, it's not important, you want your toy, even though no one uses 
it.  Enjoy it. :)


If you want to be part of an exclusive club that only uses esoteric 
tools and home-built Rube Goldberg scripts to accomplish what people are 
doing with modern tools in less than half the time and in the same 
conversation be annoyed that there's a lack of people signing up to work 
under those conditions then you need to take a deep breath and look in 
the mirror.


When your toy has a huge community that fulfills the requirements that I 
have I'll check it out.  When switching to Aegis gets FreeBSD the same 
benefits of the github community and millions of code monkeys I'll be 
cheering for it.


But right now here's what I think of a better tool that no one uses:  
http://www.youtube.com/watch?v=uuyUA-8toJk#t=27


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sun, Jan 26, 2014 at 10:00 PM, Alfred Perlstein alf...@freebsd.orgwrote:


 I'm not addicted to newness.  I think you just hate anything that is
 popular and you're butthurt that something that's may have been ahead of
 it's time was missed out on.  This is no reason to dig your heels in and
 complain as that accomplishes nothing.


I don't hate everything that's popular.  For example, I use various popular
applications such as Open Office and xfce, and I use Java.  What I hate is
stuff that doesn't work as advertised, no matter how popular.

If popularity and hordes of code monkeys (as you insultingly call them)
are so important to you, then why are you using FreeBSD instead of
Windows?  Better yet, if you like newness, how about Windows 8?


 What I am interested in is:

 1) leveraging the hordes of people that can submit changes to the project
 because they know git.


This is a non-issue because, even if the ports team uses aegis and cook,
the average port maintainer can still use svn and makefiles or whatever
build tools they like.  So the only important question here is whether
aegis and cook can save a lot of time and trouble for the ports team
specifically.


 2) leveraging the existing tooling that's available for FREE!!! for us to
 use. (instead of rewriting wheels).


Perhaps you missed this, but aegis and cook are both free and open source
(GPL).

3) reducing the overhead of contribution to our project by using existing
 solutions and not requiring accounts to be made.


Even more reason NOT to go with something that is relatively new and
largely untested in mission critical applications.  Aegis, though not
popular, is used in not just mission-critical but life-critical
applications, i.e. things that absolutely must work the first time and
every time.  For example, one aegis user is St. Jude Medical.

Have you actually installed and tested aegis are you just bad mouthing
it?   The reason for asking is it was designed on purpose to be a
plug-gable architecture... namely all aegis does except for enforcing the
dev/review/integrate cycle is act as a glue for *EXISTING* tools (see the
manual for a full list of ones supported out the box and the requirements
new ones must meet [note cook is used not make only because make is not
powerful enough to take full advantage of aegis]


 So what would using this aegis system buy us?


See http://osdir.com/ml/version-control.aegis.user/2005-05/msg1.htmlfor
a discussion of using it in linux kernel development


 1) doesn't have hordes of people that know how to use it.
 2) doesn't have a free hosting solution for it which provides tooling we
 need for free.


Why does an internal version control system need any kind of web hosting at
all?  Be that as it may, aegis does have a web front end -- including RSS
feed and other XML output -- as well as its command line interface.


 It's not about NEW THINGS, although NEW THINGS tend to lead to better
 systems... it's more about leveraging users and existing facilities.


?!?!?!?!? How the bleep does forcing everyone to learn something new
every 6 months lead to the ability to leverage existing users and
facilities... maybe my logic is faulty but isn't this almost a guarantee
that no one will know what they are talking about because stuff moves too
fast for them to keep up?

I would rather see a list (even if a small list) of solid users who all use
the system for mission critical apps (like hospitals).


 Anyhow, it's not important, you want your toy, even though no one uses it.
  Enjoy it. :)


For a list of some aegis users (every single one uses it for mission
critical systems) see http://aegis.sourceforge.net/propaganda/sites.html


 If you want to be part of an exclusive club that only uses esoteric
 tools and home-built Rube Goldberg scripts to accomplish what people are
 doing with modern tools in less than half the time


Aegis itself does not require scripts, although it can be used to
encapsulate scripts.  Every routine action (including distribution of
baselines) is already encapsulated into a single command that typically
requires only one or two arguments, in contrast to the much more
complicated command lines associated with github's api (via cURL).  For
example, we use the following command line to create a new release of
petitecloud:

  aeb cook-blank/deploy-remote

and a normal everyday build requires just:

 aeb

 and in the same conversation be annoyed that there's a lack of people
 signing up to work under those conditions then you need to take a deep
 breath and look in the mirror.

 When your toy has a huge community that fulfills the requirements that I
 have I'll check it out.  When switching to Aegis gets FreeBSD the same
 benefits of the github community and millions of code monkeys I'll be
 cheering for it.


If having a million code monkeys is the mark of a good system, does this
mean you regard healthcare.gov as a supreme master piece of software
engineering?  After

Re: What is the problem with ports PR reaction delays?


On 1/26/14 9:02 PM, Aryeh Friedman wrote:




On Sun, Jan 26, 2014 at 10:00 PM, Alfred Perlstein alf...@freebsd.org 
mailto:alf...@freebsd.org wrote:


When your toy has a huge community that fulfills the requirements
that I have I'll check it out.  When switching to Aegis gets
FreeBSD the same benefits of the github community and millions of
code monkeys I'll be cheering for it.


If having a million code monkeys is the mark of a good system, does 
this mean you regard healthcare.gov http://healthcare.gov as a 
supreme master piece of software engineering?  After all it has 500 
million lines from god knows how many contributors... therefore it 
must be better?




I'm not sure, I'm going to go load up healthcare.gov to see if I can 
order myself some free aspirin after this discussion.


I skimmed the rest of your message and nothing really stuck out as 
something worth perusing.  I guess I have to say is that I hope you 
enjoy Agis so much that you and the 10 other people using it are able to 
proselytize it to the success that git and github have had. You 
certainly seem passionate about it!


-Alfred



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein alf...@freebsd.orgwrote:


 I'm not sure, I'm going to go load up healthcare.gov to see if I can
 order myself some free aspirin after this discussion.


At least my build system has never caused me to need an aspirin (normal
debugging is bad enough).  Sarcasm aside, to bring this thread back on
track, the important issues are:

  * The development model used by aegis is likely the cleanest development
cycle I have seen (main reason for this is Peter Miller is one of the few
SCM and build management theorists [vs. just hacking something til it
works]).   The model is namely (repeat as needed)
develop-test-review-integrate... note that test comes before review for
the simple reason to even get to review you must build correctly and pass
all your own tests (isn't this the main goal of automating the port system
anyways)... also keep in mind we can use this model without necessarily
switching to aegis per se.  With or without aegis, it would save the ports
team a lot of time to be able to build and test a port automatically before
they spend any time reviewing the code.  Aegis, by default, enforces this
model.

  * GitHub *REQUIRES* all developers (including all port maintainers -- not
just the committers) to switch to GitHub.  On the other hand, if the ports
team were to use aegis and/or cook, this would NOT require any changes at
all from the POV of maintainers.  Even on the ports team, most members
would need to learn nothing more than 6 new basic commands...
(portmgr@would need to learn a lot more though depending on what kind
of
non-standard processing needs to be done in integration).

  * If there are modifications to the overall port system, switching to
aegis and/or cook would not require changes to individual ports like GitHub
seems to


 I skimmed the rest of your message and nothing really stuck out as
 something worth perusing.  I guess I have to say is that I hope you enjoy
 Agis so much that you and the 10 other people using it are able to
 proselytize it to the success that git and github have had.  You certainly
 seem passionate about it!


It would be nice if you could refrain from commenting on stuff you can't be
bothered to peruse.



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/26/14, 10:56 PM, Aryeh Friedman wrote:


On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein alf...@freebsd.org 
mailto:alf...@freebsd.org wrote:



I'm not sure, I'm going to go load up healthcare.gov
http://healthcare.gov to see if I can order myself some free
aspirin after this discussion.


At least my build system has never caused me to need an aspirin 
(normal debugging is bad enough).  Sarcasm aside, to bring this thread 
back on track, the important issues are:


  * The development model used by aegis is likely the cleanest 
development cycle I have seen (main reason for this is Peter Miller is 
one of the few SCM and build management theorists [vs. just hacking 
something til it works]).   The model is namely (repeat as needed) 
develop-test-review-integrate... note that test comes before review 
for the simple reason to even get to review you must build correctly 
and pass all your own tests (isn't this the main goal of automating 
the port system anyways)... also keep in mind we can use this model 
without necessarily switching to aegis per se.  With or without aegis, 
it would save the ports team a lot of time to be able to build and 
test a port automatically before they spend any time reviewing the 
code.  Aegis, by default, enforces this model.


  * GitHub *REQUIRES* all developers (including all port maintainers 
-- not just the committers) to switch to GitHub.  On the other hand, 
if the ports team were to use aegis and/or cook, this would NOT 
require any changes at all from the POV of maintainers.  Even on the 
ports team, most members would need to learn nothing more than 6 new 
basic commands... (portmgr@ would need to learn a lot more though 
depending on what kind of non-standard processing needs to be done in 
integration).
Using git doesn't require switching to github.  I'm not sure what you're 
smoking that's leading you to believe that, maybe you should also try to 
log onto healthcare.gov to figure out what's causing your level of 
confusion!





  * If there are modifications to the overall port system, switching 
to aegis and/or cook would not require changes to individual ports 
like GitHub seems to



I skimmed the rest of your message and nothing really stuck out as
something worth perusing.  I guess I have to say is that I hope
you enjoy Agis so much that you and the 10 other people using it
are able to proselytize it to the success that git and github have
had.  You certainly seem passionate about it!


It would be nice if you could refrain from commenting on stuff you 
can't be bothered to peruse.


Likewise!

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Mon, Jan 27, 2014 at 1:59 AM, Alfred Perlstein alf...@freebsd.orgwrote:


 On 1/26/14, 10:56 PM, Aryeh Friedman wrote:


 On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein alf...@freebsd.orgwrote:


 I'm not sure, I'm going to go load up healthcare.gov to see if I can
 order myself some free aspirin after this discussion.


  At least my build system has never caused me to need an aspirin (normal
 debugging is bad enough).  Sarcasm aside, to bring this thread back on
 track, the important issues are:

* The development model used by aegis is likely the cleanest
 development cycle I have seen (main reason for this is Peter Miller is one
 of the few SCM and build management theorists [vs. just hacking something
 til it works]).   The model is namely (repeat as needed)
 develop-test-review-integrate... note that test comes before review for
 the simple reason to even get to review you must build correctly and pass
 all your own tests (isn't this the main goal of automating the port system
 anyways)... also keep in mind we can use this model without necessarily
 switching to aegis per se.  With or without aegis, it would save the ports
 team a lot of time to be able to build and test a port automatically before
 they spend any time reviewing the code.  Aegis, by default, enforces this
 model.

* GitHub *REQUIRES* all developers (including all port maintainers --
 not just the committers) to switch to GitHub.  On the other hand, if the
 ports team were to use aegis and/or cook, this would NOT require any
 changes at all from the POV of maintainers.  Even on the ports team, most
 members would need to learn nothing more than 6 new basic commands...
 (portmgr@ would need to learn a lot more though depending on what kind of
 non-standard processing needs to be done in integration).

 Using git doesn't require switching to github.  I'm not sure what you're
 smoking that's leading you to believe that, maybe you should also try to
 log onto healthcare.gov to figure out what's causing your level of
 confusion!


Again not 100% correct. it does require you to have githup-like
functionality (githup or a clone of it) if you want to do any sort of
distributed repos... aegis does not (all of its distributions are in normal
formats like tar.gz and patches [these are automatically generated on
demand])... and more importantly your solution seems to revolve around
requiring the use of a tool over the model that it enforces (which can be
done by many different tools) have you ever heard of making your
requirements technology neutral and *THEN* seeing what techs (if any) fit
the bill... this is how we found aegis in the first place...   in some
cases we may find (and I think the current port system may be one of these
cases) that no new tools are needed; all that is needed is the reorganizing
of existing manual procedures (which can then later be automated if
desired).


* If there are modifications to the overall port system, switching to
 aegis and/or cook would not require changes to individual ports like GitHub
 seems to


 I skimmed the rest of your message and nothing really stuck out as
 something worth perusing.  I guess I have to say is that I hope you enjoy
 Agis so much that you and the 10 other people using it are able to
 proselytize it to the success that git and github have had.  You certainly
 seem passionate about it!


  It would be nice if you could refrain from commenting on stuff you can't
 be bothered to peruse.


 Likewise!


I at least took the time to check what GitHub could do and what it and what
it couldn't... this is just common sense when criticizing something



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 01/24/2014 20:16, Alfred Perlstein wrote:
(maybe there is some great ports system that I'm not aware of that 
makes this all as easy github, but I somehow doubt that.)


github itself is closed source, but 95% of its functionality is based on 
git which is open. One only needs to invoke 3-4 git operations to 
support what it does on the website side. Register on the site, fork the 
project under user's login, submit a pull request, merge a fork's branch 
to the main branch. All these are basically git commands. Without the 
glossiness of github, this is not that large of a project. Submitters 
will do the rest through git.


I think, instead of tediously going through the PRs by hand, it is wiser 
to set up some system like this.


Yuri
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Fwd: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 3:11 AM, Yuri y...@rawbw.com wrote:

 On 01/24/2014 20:16, Alfred Perlstein wrote:

 (maybe there is some great ports system that I'm not aware of that makes
 this all as easy github, but I somehow doubt that.)


 github itself is closed source, but 95% of its functionality is based on
 git which is open. One only needs to invoke 3-4 git operations to support
 what it does on the website side. Register on the site, fork the project
 under user's login, submit a pull request, merge a fork's branch to the
 main branch. All these are basically git commands. Without the glossiness
 of github, this is not that large of a project. Submitters will do the rest
 through git.

 I think, instead of tediously going through the PRs by hand, it is wiser
 to set up some system like this.


This creates a n+1 problem (something that jails are not advanced enough
to completely solve but cloud computing can) just for definitional
shake a n+1 problem is based on the observation for all computer
professionals (and hobbyists)  always need at least one more machine then
they currently have (this plus some techincal issues with OpenStack
[Grizzly don't know if Havana fixes them]) is/was the primary motivator
behind petitecloud in the first place... to that end any such system would
need to set up and tare down VM's quickly as well keep a large number of
them off line but for ready running... as far as testing goes the general
method suggested in the paper I gave and eleberated in the Aegis user guide
is a good starting place (it is especially good about making sure bugs stay
fixed).

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/24/14, 11:45 PM, John Marino wrote:

On 1/25/2014 05:16, Alfred Perlstein wrote:

Thus, are you volunteering for this role?  It's not my call, but if you
really want to do clean out and triage the all PRs on an ongoing basis,
my guess is that would be very welcome and we'd figure out a way to set
that up.  It would definitely help, especially for those maintainer that
approve patches but the PRs never get opened (or set to a better state
than open).

At some point we'll have a new PR system, that fact might be having an
impact on current PRs as well...

To me it would speak of tooling as opposed to anything.
Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

The SCM part of the ports process is not the bottleneck.


Could ports take PRs in the form of pull requests on github?
Wouldn't that just turn the number of updates into a few minor clicks?

This makes a fatal and untrue assumption: That was is submitted just
needs to be committed.  In my brief experience, I can tell you that's
simply not true.  If a submission can be taken without a single change,
that is truly an exception.  It's not even the submitters fault often,
sometimes the infrastructure changes but the submitter didn't know or
account for it, or the PR came before the infrastructure change.

One can RARELY take a submission as-is.  Thus, pull requests turn into
merge conflict exercises and cause more work, not less IMO.
Your opinion is completely incorrect.  It is trivial for someone to take 
a pull request and resolve the differences and it is MUCH easier (orders 
of magnitude) to collab using git/github than it is to mail around 
patches over and over.  I really believe you don't understand how 
git/github works.






(also wouldn't it make it easier for ports submitters)?

personally I don't really think so, plus I don't see the current or
future PR system as the barrier for port submitters.


(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

I would like to see something where the submission gets tested in
Redports automatically, and automatically annotates if the port passes
on all platforms or not.  Then the submitter gets notice it needs fixing
immediately and FreeBSD folks don't have to take the PR, test it, reject
it, and state why.  That iteration can take a few cycles and automated
testing could cut that process time tremendously.
That would be interesting.  If you could get it to work with github 
you'd find a lot more people active and willing to participate.


Basically, if my workflow was:

start:
 git pull request - creates redport submission - then
   either:
 1) submission compiles and works - promotes to qualified pull 
request - either auto merged or given to maintainer to merge in 1 click.
 2) submission fails, then either I fix and resubmit the pull 
request, or I collab with the submitter to get it to work and then 
resubmit GOTO start.


That would be pretty awesome.  *A* problem (notice: not the problem) 
is that the cycle is too slow and cumbersome.  Hook this into a DVCS 
that works well and suddenly you'll see productivity take off as well as 
people willing and wanting to submit patches.


In fact it will free up time from the people that qualify the code in 
order to quality and approve more code.


That said, you'll have to be up for learning new tools, and that doesn't 
leave me very optimistic of this ever happening.


-Alfred


John




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:
(maybe there is some great ports system that I'm not aware of that 
makes this all as easy github, but I somehow doubt that.)


github itself is closed source, but 95% of its functionality is based 
on git which is open. One only needs to invoke 3-4 git operations to 
support what it does on the website side. Register on the site, fork 
the project under user's login, submit a pull request, merge a fork's 
branch to the main branch. All these are basically git commands. 
Without the glossiness of github, this is not that large of a project. 
Submitters will do the rest through git.


I think, instead of tediously going through the PRs by hand, it is 
wiser to set up some system like this.



Agreed.   +1000

Although if we go down the rabbit hole of building something like 
github that might take a while.  For now prototyping using the github 
pull methods might be a good proof of concept.  I may look into doing a 
github pull request - GNATS (src) PR gateway if time allows.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread John Marino

On 1/25/2014 09:55, Alfred Perlstein wrote:
 
 On 1/24/14, 11:45 PM, John Marino wrote:
 On 1/25/2014 05:16, Alfred Perlstein wrote:
 Thus, are you volunteering for this role?  It's not my call, but if you
 really want to do clean out and triage the all PRs on an ongoing basis,
 my guess is that would be very welcome and we'd figure out a way to set
 that up.  It would definitely help, especially for those maintainer
 that
 approve patches but the PRs never get opened (or set to a better
 state
 than open).

 At some point we'll have a new PR system, that fact might be having an
 impact on current PRs as well...
 To me it would speak of tooling as opposed to anything.
 Does the ports system have a 1 or 2 click interface for merging PRs like
 for instance github?
 The SCM part of the ports process is not the bottleneck.

 Could ports take PRs in the form of pull requests on github?
 Wouldn't that just turn the number of updates into a few minor clicks?
 This makes a fatal and untrue assumption: That was is submitted just
 needs to be committed.  In my brief experience, I can tell you that's
 simply not true.  If a submission can be taken without a single change,
 that is truly an exception.  It's not even the submitters fault often,
 sometimes the infrastructure changes but the submitter didn't know or
 account for it, or the PR came before the infrastructure change.

 One can RARELY take a submission as-is.  Thus, pull requests turn into
 merge conflict exercises and cause more work, not less IMO.
 Your opinion is completely incorrect.  It is trivial for someone to take
 a pull request and resolve the differences and it is MUCH easier (orders
 of magnitude) to collab using git/github than it is to mail around
 patches over and over.  I really believe you don't understand how
 git/github works.

First, that's presumptuous.  I have a github account that I use.  DPorts
and DeltaPorts are both hosted on GitHub, and based on git.  I know how
what it can do.

Secondly, ports is SVN, not git, and it's not going to be based on git.
 So it's a moot discussion.

Thirdly, we don't mail patches around.  You just pull the patch from
GNATS.  Applying patches is not hard.  I personally prefer rejected
hunks than editing merge conflicts.  Sure I can do both.  I find
rejected hunks easier to deal with than yours/his/merged/common etc.

Lastly: you are skipping steps.  There's review and testing to be done.
 You don't just merge and commit.  Using pull requests (even if it were
possible on SVN) doesn't significantly change anything.

 
 

 (also wouldn't it make it easier for ports submitters)?
 personally I don't really think so, plus I don't see the current or
 future PR system as the barrier for port submitters.

 (maybe there is some great ports system that I'm not aware of that makes
 this all as easy github, but I somehow doubt that.)
 I would like to see something where the submission gets tested in
 Redports automatically, and automatically annotates if the port passes
 on all platforms or not.  Then the submitter gets notice it needs fixing
 immediately and FreeBSD folks don't have to take the PR, test it, reject
 it, and state why.  That iteration can take a few cycles and automated
 testing could cut that process time tremendously.
 That would be interesting.  If you could get it to work with github
 you'd find a lot more people active and willing to participate.
 
 Basically, if my workflow was:
 
 start:
  git pull request - creates redport submission - then
either:
  1) submission compiles and works - promotes to qualified pull
 request - either auto merged or given to maintainer to merge in 1 click.
  2) submission fails, then either I fix and resubmit the pull
 request, or I collab with the submitter to get it to work and then
 resubmit GOTO start.

Well, that's not what I said above.  That gets freebsd committers
involved before the patch is verified to build.  I was trying to get
freebsd committers not to see patches that don't even build and make
sure they get fixed before committers spend any time on it.

 That said, you'll have to be up for learning new tools, and that doesn't
 leave me very optimistic of this ever happening.


IIUC, you are trying to start a git migration from subversion
discussion.  While I am happy with either one (given that DragonFly
Ports and sources is hosted on git), I don't see the acceptance by
others.  The use git tools and/or github discussion is not going to go
far, no.  It's not a new tools thing either.  The replace of GNATS is a
big tool change that freebsd people are impatiently waiting for.

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Big Lebowski

On Sat, Jan 25, 2014 at 12:47 AM, John Marino freebsd.cont...@marino.stwrote:

 On 1/25/2014 01:36, Big Lebowski wrote:
  I was hoping to get some discussion revealing how the work is organized
  around ports PR, perhaps some ideas on improving them and I hoped that
  people who can make decisions and changes would notice it and consider
  them, since as they say, the squeeky wheel gets the grease, that's all.
 At
  no point I insisted on forcing anyone to anything, and I dont think
 that's
  neither only nor a viable solution.
 
  It seems obvious that current process doesnt work very well, then I'd aim
  at reorganizing that process - it appears that there is no roles
 specified,
  so the responsibility is blurred, and when everyone is responsible for
 one
  thing, in practice no one is. Perhaps role assignment could be of any
 help?

 I'm not trying to be a jerk, but surely I'm coming off that way.
 Again, nobody is obligated to accept any assignment.  They have to
 volunteer to do it.  The only person that The Big Lebowski can influence
 here is himself.


You are right, but that doesnt mean we cant speak about the problem and ask
if there are other people seeing it and maybe willing to help fixing it.
That is not equal to forcing anyone to do anything, but rather in a spirit
of open source volunteering and at the end it doesnt harm anyone, even if
there's no good result out of it.



 Thus, are you volunteering for this role?  It's not my call, but if you
 really want to do clean out and triage the all PRs on an ongoing basis,
 my guess is that would be very welcome and we'd figure out a way to set
 that up.  It would definitely help, especially for those maintainer that
 approve patches but the PRs never get opened (or set to a better state
 than open).


If I wouldnt care about FreeBSD and ports state and I wouldnt want to help
with that, I would have not wrote this message in first place. Yes, I would
love to help.



 At some point we'll have a new PR system, that fact might be having an
 impact on current PRs as well...


At what point? Are there any plans, someone said he's working on it, are
there any decisions? I am not trying to attack your statement, but simply
get some information about the current state of things.



 John
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Big Lebowski

On Sat, Jan 25, 2014 at 8:55 AM, Alfred Perlstein alf...@freebsd.orgwrote:


 On 1/24/14, 11:45 PM, John Marino wrote:

 On 1/25/2014 05:16, Alfred Perlstein wrote:

 Thus, are you volunteering for this role?  It's not my call, but if you
 really want to do clean out and triage the all PRs on an ongoing basis,
 my guess is that would be very welcome and we'd figure out a way to set
 that up.  It would definitely help, especially for those maintainer that
 approve patches but the PRs never get opened (or set to a better state
 than open).

 At some point we'll have a new PR system, that fact might be having an
 impact on current PRs as well...

 To me it would speak of tooling as opposed to anything.
 Does the ports system have a 1 or 2 click interface for merging PRs like
 for instance github?

 The SCM part of the ports process is not the bottleneck.

  Could ports take PRs in the form of pull requests on github?
 Wouldn't that just turn the number of updates into a few minor clicks?

 This makes a fatal and untrue assumption: That was is submitted just
 needs to be committed.  In my brief experience, I can tell you that's
 simply not true.  If a submission can be taken without a single change,
 that is truly an exception.  It's not even the submitters fault often,
 sometimes the infrastructure changes but the submitter didn't know or
 account for it, or the PR came before the infrastructure change.

 One can RARELY take a submission as-is.  Thus, pull requests turn into
 merge conflict exercises and cause more work, not less IMO.

 Your opinion is completely incorrect.  It is trivial for someone to take a
 pull request and resolve the differences and it is MUCH easier (orders of
 magnitude) to collab using git/github than it is to mail around patches
 over and over.  I really believe you don't understand how git/github works.




  (also wouldn't it make it easier for ports submitters)?

 personally I don't really think so, plus I don't see the current or
 future PR system as the barrier for port submitters.

  (maybe there is some great ports system that I'm not aware of that makes
 this all as easy github, but I somehow doubt that.)

 I would like to see something where the submission gets tested in
 Redports automatically, and automatically annotates if the port passes
 on all platforms or not.  Then the submitter gets notice it needs fixing
 immediately and FreeBSD folks don't have to take the PR, test it, reject
 it, and state why.  That iteration can take a few cycles and automated
 testing could cut that process time tremendously.

 That would be interesting.  If you could get it to work with github you'd
 find a lot more people active and willing to participate.

 Basically, if my workflow was:

 start:
  git pull request - creates redport submission - then
either:
  1) submission compiles and works - promotes to qualified pull
 request - either auto merged or given to maintainer to merge in 1 click.
  2) submission fails, then either I fix and resubmit the pull request,
 or I collab with the submitter to get it to work and then resubmit GOTO
 start.

 That would be pretty awesome.  *A* problem (notice: not the problem) is
 that the cycle is too slow and cumbersome.  Hook this into a DVCS that
 works well and suddenly you'll see productivity take off as well as people
 willing and wanting to submit patches.


This is exactly something I was thinking about: if there could be automated
process that takes the PR with a patch, tests the patch and either rejects
it or accepts it to a queue, when a human can make decision about making a
commit, changing it (goes back to automated queue) or rejecting.

Also, where a PR exists, but original sender abandoned his email and there
is no one else talking about that PR and asking for it status, acceptance
and so on, why not simply reject such PR's? Apparently the author is no
loger interested, other people are not interested (lack of comments on the
original PR or similar PR submissions) then why this really need to involve
a time of human being it no one really cares of it? If this changes, then a
new PR would be submitted, checked automatically, and then followed the
process. That would free up some human resources to do the work that counts
for people, and would reduce false amount of work that needs to be done.



 In fact it will free up time from the people that qualify the code in
 order to quality and approve more code.

 That said, you'll have to be up for learning new tools, and that doesn't
 leave me very optimistic of this ever happening.


That's a problem with *every* change, human nature doesnt like them, but I
believe if the process would really improve the experience of being
commiter for FreeBSD ports tree, they that alone would make people learn
the new tools and processes.

B.




 -Alfred


  John



 ___
 freebsd-ports@freebsd.org mailing list

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Matthew Seaman

On 25/01/2014 10:35, Big Lebowski wrote:
 Thus, are you volunteering for this role?  It's not my call, but if you
  really want to do clean out and triage the all PRs on an ongoing basis,
  my guess is that would be very welcome and we'd figure out a way to set
  that up.  It would definitely help, especially for those maintainer that
  approve patches but the PRs never get opened (or set to a better state
  than open).

 If I wouldnt care about FreeBSD and ports state and I wouldnt want to help
 with that, I would have not wrote this message in first place. Yes, I would
 love to help.

There are a lot of people who would love to help with FreeBSD, and there
is a lot of help that FreeBSD needs.  The problem is that anyone
volunteering probably only has a limited amount of time they can donate
to the project, and there exists at the moment no simple mechanism for
dividing up the workload into small, easily digestible chunks.

Take the case of PR triage, often cited as a suitable track for people
to start getting involved.  Say we get about 300 new PRs in a week.
What we need is 20--50 people looking at 6--15 PRs a week, rather than
2--5 people trying to look at 60--150 PRs a week.  Trouble is, the first
few people to volunteer will find themselves drinking from the PR
firehose, and will probably give up long before enough additional people
can be drummed up to share the load.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Bernhard Fröhlich

Am 25.01.2014 02:12 schrieb Aryeh Friedman aryeh.fried...@gmail.com:

 
  I think you've got me wrong - I am following freebsd-virtualization list
  very closely, and the matter I've touched here is not my doubt on which
  technology I should use, but rather a complaint on the state of jails
  related tools directly leading to the delays in handling of ports
related
  PR's. I know the technology alternatives, I am decided to jails for a
  reason, and I also know your work on the web interface focusing on
bhyve,
  but its not about it.
 

 My point is writing scripts for VM's is easier (nothing more then copy the
 master and then do a normal make install/portmaster on the port of you
 choice [better to run them one at a time I have found).  When I get into
 port testing I usually have 3 VM's on the host working on compiling and 1
 for development.   I have yet to find a good way to have 4 jails running
as
 independentlu.

This thread has taken a different direction at some point so I want to
throw in another view.

We already have all that build testing stuff around for various FreeBSD
versions with enough hardware resources and production ready and free for
all. It's called redports.org and I have even already created scripts that
monitor the gnats database for ports PRs with patches, fetch them, apply
them to the redports repository and schedule jobs for it.

So it is all there and the reason why it isn't running already are
political ones because I also proposed to automatically send followup mails
to the PR with the buildlog status.

http://code.google.com/p/redports/source/browse/#svn%2Ftrunk%2Fscripts
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Big Lebowski

On Sat, Jan 25, 2014 at 1:13 PM, Bernhard Fröhlich de...@bluelife.atwrote:


 Am 25.01.2014 02:12 schrieb Aryeh Friedman aryeh.fried...@gmail.com:

 
  
   I think you've got me wrong - I am following freebsd-virtualization
 list
   very closely, and the matter I've touched here is not my doubt on which
   technology I should use, but rather a complaint on the state of jails
   related tools directly leading to the delays in handling of ports
 related
   PR's. I know the technology alternatives, I am decided to jails for a
   reason, and I also know your work on the web interface focusing on
 bhyve,
   but its not about it.
  
 
  My point is writing scripts for VM's is easier (nothing more then copy
 the
  master and then do a normal make install/portmaster on the port of you
  choice [better to run them one at a time I have found).  When I get into
  port testing I usually have 3 VM's on the host working on compiling and 1
  for development.   I have yet to find a good way to have 4 jails running
 as
  independentlu.

 This thread has taken a different direction at some point so I want to
 throw in another view.

 We already have all that build testing stuff around for various FreeBSD
 versions with enough hardware resources and production ready and free for
 all. It's called redports.org and I have even already created scripts
 that monitor the gnats database for ports PRs with patches, fetch them,
 apply them to the redports repository and schedule jobs for it.

 So it is all there and the reason why it isn't running already are
 political ones because I also proposed to automatically send followup mails
 to the PR with the buildlog status.

 http://code.google.com/p/redports/source/browse/#svn%2Ftrunk%2Fscripts

That sounds great! It would be awesome to introduce both solutions
(automated testing and screening roles with new volunteers - we already
have two of those) to improve the process. However, I hate when I hear
'politics' in open source projects. Could you be more specific and name the
problem, if you mentioned it?

B.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Bernhard Fröhlich

Am 25.01.2014 13:35 schrieb Big Lebowski spankthes...@gmail.com:




 On Sat, Jan 25, 2014 at 1:13 PM, Bernhard Fröhlich de...@bluelife.at
wrote:


 Am 25.01.2014 02:12 schrieb Aryeh Friedman aryeh.fried...@gmail.com:


 
  
   I think you've got me wrong - I am following freebsd-virtualization
list
   very closely, and the matter I've touched here is not my doubt on
which
   technology I should use, but rather a complaint on the state of jails
   related tools directly leading to the delays in handling of ports
related
   PR's. I know the technology alternatives, I am decided to jails for a
   reason, and I also know your work on the web interface focusing on
bhyve,
   but its not about it.
  
 
  My point is writing scripts for VM's is easier (nothing more then copy
the
  master and then do a normal make install/portmaster on the port of you
  choice [better to run them one at a time I have found).  When I get
into
  port testing I usually have 3 VM's on the host working on compiling
and 1
  for development.   I have yet to find a good way to have 4 jails
running as
  independentlu.

 This thread has taken a different direction at some point so I want to
throw in another view.

 We already have all that build testing stuff around for various FreeBSD
versions with enough hardware resources and production ready and free for
all. It's called redports.org and I have even already created scripts that
monitor the gnats database for ports PRs with patches, fetch them, apply
them to the redports repository and schedule jobs for it.

 So it is all there and the reason why it isn't running already are
political ones because I also proposed to automatically send followup mails
to the PR with the buildlog status.

 http://code.google.com/p/redports/source/browse/#svn%2Ftrunk%2Fscripts

 That sounds great! It would be awesome to introduce both solutions
(automated testing and screening roles with new volunteers - we already
have two of those) to improve the process.

With the scripts it should be possible to fetch the patch of a PR, apply
and commit it to your redports repository and do additional changes until
you are okay with it. What is still missing is a script that helps
committing the changes to the FreeBSD tree but it's really not that
complicated to write that.

 However, I hate when I hear 'politics' in open source projects. Could you
be more specific and name the problem, if you mentioned it?

The raised concerns were that automatic build testing might result in less
testing on committer side. I agree that this might happen and automatic
build testing is only one part of what committers need to do. A huge
backlog and no response for months is definitely nothing we want.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/25/14, 1:14 AM, John Marino wrote:

On 1/25/2014 09:55, Alfred Perlstein wrote:

On 1/24/14, 11:45 PM, John Marino wrote:

On 1/25/2014 05:16, Alfred Perlstein wrote:

Thus, are you volunteering for this role?  It's not my call, but if you
really want to do clean out and triage the all PRs on an ongoing basis,
my guess is that would be very welcome and we'd figure out a way to set
that up.  It would definitely help, especially for those maintainer
that
approve patches but the PRs never get opened (or set to a better
state
than open).

At some point we'll have a new PR system, that fact might be having an
impact on current PRs as well...

To me it would speak of tooling as opposed to anything.
Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

The SCM part of the ports process is not the bottleneck.


Could ports take PRs in the form of pull requests on github?
Wouldn't that just turn the number of updates into a few minor clicks?

This makes a fatal and untrue assumption: That was is submitted just
needs to be committed.  In my brief experience, I can tell you that's
simply not true.  If a submission can be taken without a single change,
that is truly an exception.  It's not even the submitters fault often,
sometimes the infrastructure changes but the submitter didn't know or
account for it, or the PR came before the infrastructure change.

One can RARELY take a submission as-is.  Thus, pull requests turn into
merge conflict exercises and cause more work, not less IMO.

Your opinion is completely incorrect.  It is trivial for someone to take
a pull request and resolve the differences and it is MUCH easier (orders
of magnitude) to collab using git/github than it is to mail around
patches over and over.  I really believe you don't understand how
git/github works.

First, that's presumptuous.  I have a github account that I use.  DPorts
and DeltaPorts are both hosted on GitHub, and based on git.  I know how
what it can do.

Secondly, ports is SVN, not git, and it's not going to be based on git.
  So it's a moot discussion.


Still missing the point.  Git can sit on top of svn.


Thirdly, we don't mail patches around.  You just pull the patch from
GNATS.  Applying patches is not hard.  I personally prefer rejected
hunks than editing merge conflicts.  Sure I can do both.  I find
rejected hunks easier to deal with than yours/his/merged/common etc.


Basically we don't carry floppies from computer to computer!!!  we use 
zip disks!! mlaaah.


OK, got it!

From what I'm reading you may know how to use git casually, but not in 
any other fashion than it's like svn, but I have to commit twice.



Lastly: you are skipping steps.  There's review and testing to be done.
  You don't just merge and commit.  Using pull requests (even if it were
possible on SVN) doesn't significantly change anything.


I'm not skipping steps if you read the rest of my mail.


(also wouldn't it make it easier for ports submitters)?

personally I don't really think so, plus I don't see the current or
future PR system as the barrier for port submitters.


(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

I would like to see something where the submission gets tested in
Redports automatically, and automatically annotates if the port passes
on all platforms or not.  Then the submitter gets notice it needs fixing
immediately and FreeBSD folks don't have to take the PR, test it, reject
it, and state why.  That iteration can take a few cycles and automated
testing could cut that process time tremendously.

That would be interesting.  If you could get it to work with github
you'd find a lot more people active and willing to participate.

Basically, if my workflow was:

start:
  git pull request - creates redport submission - then
either:
  1) submission compiles and works - promotes to qualified pull
request - either auto merged or given to maintainer to merge in 1 click.
  2) submission fails, then either I fix and resubmit the pull
request, or I collab with the submitter to get it to work and then
resubmit GOTO start.

Well, that's not what I said above.  That gets freebsd committers
involved before the patch is verified to build.  I was trying to get
freebsd committers not to see patches that don't even build and make
sure they get fixed before committers spend any time on it.


That said, you'll have to be up for learning new tools, and that doesn't
leave me very optimistic of this ever happening.

IIUC, you are trying to start a git migration from subversion
discussion.
No you do not IIUC.  The point here is to encourage the use of 
existing tooling to solve a problem or enhance a process.



While I am happy with either one (given that DragonFly
Ports and sources is hosted on git), I don't see the acceptance by
others.
Yes, because change can never happen because some people don't like 
change.  Sad.

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread John Marino

On 1/25/2014 18:11, Alfred Perlstein wrote:
 
 Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


 From what I'm reading you may know how to use git casually, but not in
 any other fashion than it's like svn, but I have to commit twice.

So you continue to be make bad assumptions then.
I am a committer to DragonFly.  We use git for src and ports.  We use it
more than casually.  The maintenance of vendor branches is not standard
at all, for example.


 One can very easily use git-svn bridge to push git changes into
 subversion. Or you can try to re-implement a patch queue based system
 yourself using a bunch of duct tape and bailing wire and likely get
 frustrated and either never complete it OR complete it and it's just not
 even half as good as git as a patch manager.

It's a solution looking for a problem.  I'm not hearing anyone grip
about the patches.  It's not the bottleneck.  I can only conjecture, but
I from what I've seen, there's no way git bridges will be accepted as
official methods.


 Use the existing tools.
 
 I implore you to explore the idea of using existing tools to solve the
 problem, or at least solve a part of the problem, instead of trying to
 reinvent functionality that already exists.


You are solving the wrong problem.
And nobody is reinventing anything, which is weird to say because
GNATS is far older than git and github.  The tool set, archaic or not,
is not presenting any kind of bottleneck.

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

 By the way, this wasn't about switching to git (although that would be
 nice), this is about leveraging existing tools.

 One can very easily use git-svn bridge to push git changes into
 subversion. Or you can try to re-implement a patch queue based system
 yourself using a bunch of duct tape and bailing wire and likely get
 frustrated and either never complete it OR complete it and it's just not
 even half as good as git as a patch manager.

 Use the existing tools.

 I implore you to explore the idea of using existing tools to solve the
 problem, or at least solve a part of the problem, instead of trying to
 reinvent functionality that already exists


devel/tailor (which I maintain but never used) is designed to automatic
convert repos from one scm to an other this might be the best solution...
also I think the devel/aegis model of develop--test--review--integrate
(which is built in by default but can be turned of or configured) might
help here (no need for changing tools unless we want to since most of this
is procedural) the basic model is:

1. One person develops
2. An other reviews
3. Yet an other intergates

I think the first 2 is what we need to focus on.   Namely when a new port
comes it is assigned a perm reviewer/integrator (aka comitter) and all
changes to that port from hence forth have that person as the assigned
comitter

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?



On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.

I encourage you to educate yourself then and then review the suggestions 
I gave.


Continuing the discussion at this point would prove worthless.

Here are some links to get yourself started:

git-svn:
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
http://viget.com/extend/effectively-using-git-with-subversion

gerrit: a tool for review and automation of code submission:
http://code.google.com/p/gerrit/

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:
 
 On 1/24/14, 4:47 PM, John Marino wrote:
  On 1/25/2014 01:36, Big Lebowski wrote:
  I was hoping to get some discussion revealing how the work is organized
  around ports PR, perhaps some ideas on improving them and I hoped that
  people who can make decisions and changes would notice it and consider
  them, since as they say, the squeeky wheel gets the grease, that's all. At
  no point I insisted on forcing anyone to anything, and I dont think that's
  neither only nor a viable solution.
 
  It seems obvious that current process doesnt work very well, then I'd aim
  at reorganizing that process - it appears that there is no roles specified,
  so the responsibility is blurred, and when everyone is responsible for one
  thing, in practice no one is. Perhaps role assignment could be of any help?
  I'm not trying to be a jerk, but surely I'm coming off that way.
  Again, nobody is obligated to accept any assignment.  They have to
  volunteer to do it.  The only person that The Big Lebowski can influence
  here is himself.
 
  Thus, are you volunteering for this role?  It's not my call, but if you
  really want to do clean out and triage the all PRs on an ongoing basis,
  my guess is that would be very welcome and we'd figure out a way to set
  that up.  It would definitely help, especially for those maintainer that
  approve patches but the PRs never get opened (or set to a better state
  than open).
 
  At some point we'll have a new PR system, that fact might be having an
  impact on current PRs as well...
 
 To me it would speak of tooling as opposed to anything.
 
 Does the ports system have a 1 or 2 click interface for merging PRs like 
 for instance github?
 
 Could ports take PRs in the form of pull requests on github?
 
 Wouldn't that just turn the number of updates into a few minor clicks?
 
 (also wouldn't it make it easier for ports submitters)?
 
 (maybe there is some great ports system that I'm not aware of that makes 
 this all as easy github, but I somehow doubt that.)

That would imho be a total disaster, as less and less people will really take
care of reviewing the actual patch (lots of commits are already directly from Pr
patches without applying some necessary diff for consistency, correctness, Q/A
and cosmetic.)

btw we already have tons of tools available to just merge patches directly from
gnats.

regards,
Bapt


pgp8rvxuUaVQ6.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:
 
 On 1/25/14, 12:11 AM, Yuri wrote:
  On 01/24/2014 20:16, Alfred Perlstein wrote:
  (maybe there is some great ports system that I'm not aware of that 
  makes this all as easy github, but I somehow doubt that.)
 
  github itself is closed source, but 95% of its functionality is based 
  on git which is open. One only needs to invoke 3-4 git operations to 
  support what it does on the website side. Register on the site, fork 
  the project under user's login, submit a pull request, merge a fork's 
  branch to the main branch. All these are basically git commands. 
  Without the glossiness of github, this is not that large of a project. 
  Submitters will do the rest through git.
 
  I think, instead of tediously going through the PRs by hand, it is 
  wiser to set up some system like this.
 
 Agreed.   +1000
 
 Although if we go down the rabbit hole of building something like 
 github that might take a while.  For now prototyping using the github 
 pull methods might be a good proof of concept.  I may look into doing a 
 github pull request - GNATS (src) PR gateway if time allows.

Once again github pull request is the worst way of merging patches that exists.

We already have problem with ugly and inaccurate logs, such pull request will
make it even worse.

Making proper merge from github pull request it not that easy, you will need to
fetch pull request as custom branches and cherry-pick them. That is really not
convenient.

regards,
Bapt


pgpznRRtp0I9J.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

Making proper merge from github pull request it not that easy, you will
 need to
 fetch pull request as custom branches and cherry-pick them. That is really
 not
 convenient.


devel/tailor was designed specifically for this case (the actual case it
does is aegis --- svn) but same basic idea
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Fwd: What is the problem with ports PR reaction delays?

-- Forwarded message --
From: Aryeh Friedman aryeh.fried...@gmail.com
Date: Sat, Jan 25, 2014 at 12:34 PM
Subject: Re: What is the problem with ports PR reaction delays?
To: John Marino dragonfly...@marino.st




 You are solving the wrong problem.
 And nobody is reinventing anything, which is weird to say because
 GNATS is far older than git and github.  The tool set, archaic or not,
 is not presenting any kind of bottleneck.


It should be trivial to see if a port at least builds and that can be
automated I am willing to bet 80% of new ports will not pass this test on
the first try and thus 80% of the back log can eliminated right away


 John
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 09:11:24AM -0800, Alfred Perlstein wrote:
 
 On 1/25/14, 1:14 AM, John Marino wrote:
  On 1/25/2014 09:55, Alfred Perlstein wrote:
  On 1/24/14, 11:45 PM, John Marino wrote:
  On 1/25/2014 05:16, Alfred Perlstein wrote:
  Thus, are you volunteering for this role?  It's not my call, but if you
  really want to do clean out and triage the all PRs on an ongoing basis,
  my guess is that would be very welcome and we'd figure out a way to set
  that up.  It would definitely help, especially for those maintainer
  that
  approve patches but the PRs never get opened (or set to a better
  state
  than open).
 
  At some point we'll have a new PR system, that fact might be having an
  impact on current PRs as well...
  To me it would speak of tooling as opposed to anything.
  Does the ports system have a 1 or 2 click interface for merging PRs like
  for instance github?
  The SCM part of the ports process is not the bottleneck.
 
  Could ports take PRs in the form of pull requests on github?
  Wouldn't that just turn the number of updates into a few minor clicks?
  This makes a fatal and untrue assumption: That was is submitted just
  needs to be committed.  In my brief experience, I can tell you that's
  simply not true.  If a submission can be taken without a single change,
  that is truly an exception.  It's not even the submitters fault often,
  sometimes the infrastructure changes but the submitter didn't know or
  account for it, or the PR came before the infrastructure change.
 
  One can RARELY take a submission as-is.  Thus, pull requests turn into
  merge conflict exercises and cause more work, not less IMO.
  Your opinion is completely incorrect.  It is trivial for someone to take
  a pull request and resolve the differences and it is MUCH easier (orders
  of magnitude) to collab using git/github than it is to mail around
  patches over and over.  I really believe you don't understand how
  git/github works.
  First, that's presumptuous.  I have a github account that I use.  DPorts
  and DeltaPorts are both hosted on GitHub, and based on git.  I know how
  what it can do.
 
  Secondly, ports is SVN, not git, and it's not going to be based on git.
So it's a moot discussion.
 
 Still missing the point.  Git can sit on top of svn.

Oh you have a nice way to allow git-svn to properly handle properties?
 
  Thirdly, we don't mail patches around.  You just pull the patch from
  GNATS.  Applying patches is not hard.  I personally prefer rejected
  hunks than editing merge conflicts.  Sure I can do both.  I find
  rejected hunks easier to deal with than yours/his/merged/common etc.
 
 Basically we don't carry floppies from computer to computer!!!  we use 
 zip disks!! mlaaah.
 
 OK, got it!
 
  From what I'm reading you may know how to use git casually, but not in 
 any other fashion than it's like svn, but I have to commit twice.
 
  Lastly: you are skipping steps.  There's review and testing to be done.
You don't just merge and commit.  Using pull requests (even if it were
  possible on SVN) doesn't significantly change anything.
 
 I'm not skipping steps if you read the rest of my mail.
 
  (also wouldn't it make it easier for ports submitters)?
  personally I don't really think so, plus I don't see the current or
  future PR system as the barrier for port submitters.
 
  (maybe there is some great ports system that I'm not aware of that makes
  this all as easy github, but I somehow doubt that.)
  I would like to see something where the submission gets tested in
  Redports automatically, and automatically annotates if the port passes
  on all platforms or not.  Then the submitter gets notice it needs fixing
  immediately and FreeBSD folks don't have to take the PR, test it, reject
  it, and state why.  That iteration can take a few cycles and automated
  testing could cut that process time tremendously.
  That would be interesting.  If you could get it to work with github
  you'd find a lot more people active and willing to participate.
 
  Basically, if my workflow was:
 
  start:
git pull request - creates redport submission - then
  either:
1) submission compiles and works - promotes to qualified pull
  request - either auto merged or given to maintainer to merge in 1 click.
2) submission fails, then either I fix and resubmit the pull
  request, or I collab with the submitter to get it to work and then
  resubmit GOTO start.
  Well, that's not what I said above.  That gets freebsd committers
  involved before the patch is verified to build.  I was trying to get
  freebsd committers not to see patches that don't even build and make
  sure they get fixed before committers spend any time on it.
 
  That said, you'll have to be up for learning new tools, and that doesn't
  leave me very optimistic of this ever happening.
  IIUC, you are trying to start a git migration from subversion
  discussion.
 No you do not IIUC.  The point here is to encourage the

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:
 
 On 1/25/14, 9:28 AM, John Marino wrote:
  On 1/25/2014 18:11, Alfred Perlstein wrote:
  Still missing the point.  Git can sit on top of svn.
 
  Other than converting SVN to Git, I don't know anything about that.  It
  would never be done in an official capacity.  Git is not an official
  tool of FreeBSD.
 
 I encourage you to educate yourself then and then review the suggestions 
 I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.
 
 Continuing the discussion at this point would prove worthless.
 
 Here are some links to get yourself started:
 
 git-svn:
 https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
 http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
 http://viget.com/extend/effectively-using-git-with-subversion
 
 gerrit: a tool for review and automation of code submission:
 http://code.google.com/p/gerrit/

phabricator will definitly give us more flexibility and work closer to our
requirements, instead of
pull request you will have new reviews, the arc command allows you to fetch
the review and apply it to your working copy, it plays nicely with git, hg _and_
svn.

http://phabricator.org/

regards,
Bapt


pgpyN9ZXCqxCJ.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 12:53:41PM -0500, Aryeh Friedman wrote:
 Making proper merge from github pull request it not that easy, you will
  need to
  fetch pull request as custom branches and cherry-pick them. That is really
  not
  convenient.
 
 
 devel/tailor was designed specifically for this case (the actual case it
 does is aegis --- svn) but same basic idea

Well website is broken for now, I can have a look :)

regards,
Bapt


pgpH1zsM_7EwZ.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?


On 1/25/14 9:48 AM, Baptiste Daroussin wrote:

On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:


To me it would speak of tooling as opposed to anything.

Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

Could ports take PRs in the form of pull requests on github?

Wouldn't that just turn the number of updates into a few minor clicks?

(also wouldn't it make it easier for ports submitters)?

(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

That would imho be a total disaster, as less and less people will really take
care of reviewing the actual patch (lots of commits are already directly from Pr
patches without applying some necessary diff for consistency, correctness, Q/A
and cosmetic.)



You are not serious.

You are saying that because the process would be too streamlined that 
quality would be impacted?


That is pretty entertaining.  I've seen such positions, but only at very 
large and derpy companies coming from people invested in broken tooling.



btw we already have tons of tools available to just merge patches directly from
gnats.

Are any of these tools available on the other side?

Ie, for port submitters?

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 9:51 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:

On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:

(maybe there is some great ports system that I'm not aware of that
makes this all as easy github, but I somehow doubt that.)

github itself is closed source, but 95% of its functionality is based
on git which is open. One only needs to invoke 3-4 git operations to
support what it does on the website side. Register on the site, fork
the project under user's login, submit a pull request, merge a fork's
branch to the main branch. All these are basically git commands.
Without the glossiness of github, this is not that large of a project.
Submitters will do the rest through git.

I think, instead of tediously going through the PRs by hand, it is
wiser to set up some system like this.


Agreed.   +1000

Although if we go down the rabbit hole of building something like
github that might take a while.  For now prototyping using the github
pull methods might be a good proof of concept.  I may look into doing a
github pull request - GNATS (src) PR gateway if time allows.

Once again github pull request is the worst way of merging patches that exists.

We already have problem with ugly and inaccurate logs, such pull request will
make it even worse.

Making proper merge from github pull request it not that easy, you will need to
fetch pull request as custom branches and cherry-pick them. That is really not
convenient.

Probably a dozen lines of shell.

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.


Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 10:25:07AM -0800, Alfred Perlstein wrote:
 On 1/25/14 9:48 AM, Baptiste Daroussin wrote:
  On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:
 
  To me it would speak of tooling as opposed to anything.
 
  Does the ports system have a 1 or 2 click interface for merging PRs like
  for instance github?
 
  Could ports take PRs in the form of pull requests on github?
 
  Wouldn't that just turn the number of updates into a few minor clicks?
 
  (also wouldn't it make it easier for ports submitters)?
 
  (maybe there is some great ports system that I'm not aware of that makes
  this all as easy github, but I somehow doubt that.)
  That would imho be a total disaster, as less and less people will really 
  take
  care of reviewing the actual patch (lots of commits are already directly 
  from Pr
  patches without applying some necessary diff for consistency, correctness, 
  Q/A
  and cosmetic.)
 
 
 You are not serious.
 
 You are saying that because the process would be too streamlined that 
 quality would be impacted?
 
 That is pretty entertaining.  I've seen such positions, but only at very 
 large and derpy companies coming from people invested in broken tooling.

I m saying that such tools as they are, are giving awful result, if we are ever
going to that can of direction, we will need to really take time to work on the
workflow and the tools, to make sure this is done a proper way, and no githun is
not doing such things a proper way, I did learn that the hardway with pkgng
developememt which is on github, I do not use anymorr at all their web tools to
do any merge.
 
  btw we already have tons of tools available to just merge patches directly 
  from
  gnats.
 Are any of these tools available on the other side?
 
 Ie, for port submitters?

yes porttools for example, or some scripts inside Tools/scripts 

regards,
Bapt


pgph78w14pZ6X.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:
 On 1/25/14 10:04 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:
  On 1/25/14, 9:28 AM, John Marino wrote:
  On 1/25/2014 18:11, Alfred Perlstein wrote:
  Still missing the point.  Git can sit on top of svn.
 
  Other than converting SVN to Git, I don't know anything about that.  It
  would never be done in an official capacity.  Git is not an official
  tool of FreeBSD.
 
  I encourage you to educate yourself then and then review the suggestions
  I gave.
  I encourage you to give a shot at what you are suggesting. git-svn is 
  broken for
  committers as long as it doesn't properly handle properties.
 
 Or maybe our requirement for props is broken?
 
 Is $FreeBSD$ *that* important?
 
 -Alfred

There is not only $Freebsd$ but also other props.

regards,
Bapt


pgpgUXUjVVr1t.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?


On 1/25/14 10:32 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.

Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred

There is not only $Freebsd$ but also other props.


mergeinfo?

I'm wondering because there's huge projects out there not tied down to 
svn.  It seems to be a problem of our own invention.


Having managed the FreeNAS project for a year and exclusively using git 
we found ZERO use for any svn props.  We just used git and put all the 
cruft behind us.


And we were glad for it!

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 10:30 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:25:07AM -0800, Alfred Perlstein wrote:

On 1/25/14 9:48 AM, Baptiste Daroussin wrote:

On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:

To me it would speak of tooling as opposed to anything.

Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

Could ports take PRs in the form of pull requests on github?

Wouldn't that just turn the number of updates into a few minor clicks?

(also wouldn't it make it easier for ports submitters)?

(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

That would imho be a total disaster, as less and less people will really take
care of reviewing the actual patch (lots of commits are already directly from Pr
patches without applying some necessary diff for consistency, correctness, Q/A
and cosmetic.)



You are not serious.

You are saying that because the process would be too streamlined that
quality would be impacted?

That is pretty entertaining.  I've seen such positions, but only at very
large and derpy companies coming from people invested in broken tooling.

I m saying that such tools as they are, are giving awful result, if we are ever
going to that can of direction, we will need to really take time to work on the
workflow and the tools, to make sure this is done a proper way, and no githun is
not doing such things a proper way, I did learn that the hardway with pkgng
developememt which is on github, I do not use anymorr at all their web tools to
do any merge.

btw we already have tons of tools available to just merge patches directly from
gnats.

Are any of these tools available on the other side?

Ie, for port submitters?

yes porttools for example, or some scripts inside Tools/scripts

regards,
Bapt

Is there a primer on using these tools?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 10:41:22AM -0800, Alfred Perlstein wrote:
 On 1/25/14 10:32 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:
  On 1/25/14 10:04 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:
  On 1/25/14, 9:28 AM, John Marino wrote:
  On 1/25/2014 18:11, Alfred Perlstein wrote:
  Still missing the point.  Git can sit on top of svn.
 
  Other than converting SVN to Git, I don't know anything about that.  It
  would never be done in an official capacity.  Git is not an official
  tool of FreeBSD.
 
  I encourage you to educate yourself then and then review the suggestions
  I gave.
  I encourage you to give a shot at what you are suggesting. git-svn is 
  broken for
  committers as long as it doesn't properly handle properties.
  Or maybe our requirement for props is broken?
 
  Is $FreeBSD$ *that* important?
 
  -Alfred
  There is not only $Freebsd$ but also other props.
 
 mergeinfo?
 
 I'm wondering because there's huge projects out there not tied down to 
 svn.  It seems to be a problem of our own invention.
 
 Having managed the FreeNAS project for a year and exclusively using git 
 we found ZERO use for any svn props.  We just used git and put all the 
 cruft behind us.
 
 And we were glad for it!
 
 -Alfred

svn props are used by and for svn, sure if you are not in a svn world you do not
need the props, see the autoprops set on the repo for more details,

honnestly I do not care the vcs we use, right now it is svn so what ever is
going to be use on top of it it should be svn compliant and svn needs and uses
the properties.

regards,
Bapt


pgp72KnA4F1to.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 10:41:51AM -0800, Alfred Perlstein wrote:
 On 1/25/14 10:30 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 10:25:07AM -0800, Alfred Perlstein wrote:
  On 1/25/14 9:48 AM, Baptiste Daroussin wrote:
  On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:
  To me it would speak of tooling as opposed to anything.
 
  Does the ports system have a 1 or 2 click interface for merging PRs like
  for instance github?
 
  Could ports take PRs in the form of pull requests on github?
 
  Wouldn't that just turn the number of updates into a few minor clicks?
 
  (also wouldn't it make it easier for ports submitters)?
 
  (maybe there is some great ports system that I'm not aware of that makes
  this all as easy github, but I somehow doubt that.)
  That would imho be a total disaster, as less and less people will really 
  take
  care of reviewing the actual patch (lots of commits are already directly 
  from Pr
  patches without applying some necessary diff for consistency, 
  correctness, Q/A
  and cosmetic.)
 
 
  You are not serious.
 
  You are saying that because the process would be too streamlined that
  quality would be impacted?
 
  That is pretty entertaining.  I've seen such positions, but only at very
  large and derpy companies coming from people invested in broken tooling.
  I m saying that such tools as they are, are giving awful result, if we are 
  ever
  going to that can of direction, we will need to really take time to work on 
  the
  workflow and the tools, to make sure this is done a proper way, and no 
  githun is
  not doing such things a proper way, I did learn that the hardway with pkgng
  developememt which is on github, I do not use anymorr at all their web 
  tools to
  do any merge.
  btw we already have tons of tools available to just merge patches 
  directly from
  gnats.
  Are any of these tools available on the other side?
 
  Ie, for port submitters?
  yes porttools for example, or some scripts inside Tools/scripts
 
  regards,
  Bapt
 Is there a primer on using these tools?

I don t know I uses none of them, but one can write one, volunteering?

regards,
Bapt


pgpVArS5Ehjzm.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?


On 1/25/14 10:59 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:41:22AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:32 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.

Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred

There is not only $Freebsd$ but also other props.

mergeinfo?

I'm wondering because there's huge projects out there not tied down to
svn.  It seems to be a problem of our own invention.

Having managed the FreeNAS project for a year and exclusively using git
we found ZERO use for any svn props.  We just used git and put all the
cruft behind us.

And we were glad for it!

-Alfred

svn props are used by and for svn, sure if you are not in a svn world you do not
need the props, see the autoprops set on the repo for more details,

honnestly I do not care the vcs we use, right now it is svn so what ever is
going to be use on top of it it should be svn compliant and svn needs and uses
the properties.

regards,
Bapt

Or you just rip the band aid off and flag day your way into the future.

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 11:06:33AM -0800, Alfred Perlstein wrote:
 On 1/25/14 10:59 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 10:41:22AM -0800, Alfred Perlstein wrote:
  On 1/25/14 10:32 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:
  On 1/25/14 10:04 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:
  On 1/25/14, 9:28 AM, John Marino wrote:
  On 1/25/2014 18:11, Alfred Perlstein wrote:
  Still missing the point.  Git can sit on top of svn.
 
  Other than converting SVN to Git, I don't know anything about that.  
  It
  would never be done in an official capacity.  Git is not an official
  tool of FreeBSD.
 
  I encourage you to educate yourself then and then review the 
  suggestions
  I gave.
  I encourage you to give a shot at what you are suggesting. git-svn is 
  broken for
  committers as long as it doesn't properly handle properties.
  Or maybe our requirement for props is broken?
 
  Is $FreeBSD$ *that* important?
 
  -Alfred
  There is not only $Freebsd$ but also other props.
  mergeinfo?
 
  I'm wondering because there's huge projects out there not tied down to
  svn.  It seems to be a problem of our own invention.
 
  Having managed the FreeNAS project for a year and exclusively using git
  we found ZERO use for any svn props.  We just used git and put all the
  cruft behind us.
 
  And we were glad for it!
 
  -Alfred
  svn props are used by and for svn, sure if you are not in a svn world you 
  do not
  need the props, see the autoprops set on the repo for more details,
 
  honnestly I do not care the vcs we use, right now it is svn so what ever is
  going to be use on top of it it should be svn compliant and svn needs and 
  uses
  the properties.
 
  regards,
  Bapt
 Or you just rip the band aid off and flag day your way into the future.
 
What do you mean, switching to git? so you are volunteering to handle a switch?

That includes way more than converting the tree you know, that includes
converting all the tools we have out there to be able to use git, and there are
more than you can imagine.

That include teaching it to all our developers and given how much git can become
complex, good luck with that.

That include defining a proper workflow so that we do not fuck up with history

That include writing tons of pre-push hooks to make sure we do not shout ourself
in the foot, which git allows you to do (on pkgng I had tons of case it was hard
to figure out how to fix, and for some we just moved away and gave up on fixing)

We just recovered from cvs-svn switch I think noone at all is willing to do the
job again.

Git has lots of drawbacks and if badly handled with all the above, it will be a
real nightmare.

and That is said from someone who likes git (except that the UI can get
overcomplicated)

regards,
Bapt


pgpD57m_NXFP1.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 10:26:30AM -0800, Alfred Perlstein wrote:
 On 1/25/14 9:51 AM, Baptiste Daroussin wrote:
  On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:
  On 1/25/14, 12:11 AM, Yuri wrote:
  On 01/24/2014 20:16, Alfred Perlstein wrote:
  (maybe there is some great ports system that I'm not aware of that
  makes this all as easy github, but I somehow doubt that.)
  github itself is closed source, but 95% of its functionality is based
  on git which is open. One only needs to invoke 3-4 git operations to
  support what it does on the website side. Register on the site, fork
  the project under user's login, submit a pull request, merge a fork's
  branch to the main branch. All these are basically git commands.
  Without the glossiness of github, this is not that large of a project.
  Submitters will do the rest through git.
 
  I think, instead of tediously going through the PRs by hand, it is
  wiser to set up some system like this.
 
  Agreed.   +1000
 
  Although if we go down the rabbit hole of building something like
  github that might take a while.  For now prototyping using the github
  pull methods might be a good proof of concept.  I may look into doing a
  github pull request - GNATS (src) PR gateway if time allows.
  Once again github pull request is the worst way of merging patches that 
  exists.
 
  We already have problem with ugly and inaccurate logs, such pull request 
  will
  make it even worse.
 
  Making proper merge from github pull request it not that easy, you will 
  need to
  fetch pull request as custom branches and cherry-pick them. That is really 
  not
  convenient.
 Probably a dozen lines of shell.
 
Actually no: add this to your git config file

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then all the pull request will be seen as branches you can safely cherry-pick.

regards,
Bapt


pgpanMjKzDlXA.pgp
Description: PGP signature

Re: What is the problem with ports PR reaction delays?


On 1/25/14 11:52 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:26:30AM -0800, Alfred Perlstein wrote:

On 1/25/14 9:51 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:

On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:

(maybe there is some great ports system that I'm not aware of that
makes this all as easy github, but I somehow doubt that.)

github itself is closed source, but 95% of its functionality is based
on git which is open. One only needs to invoke 3-4 git operations to
support what it does on the website side. Register on the site, fork
the project under user's login, submit a pull request, merge a fork's
branch to the main branch. All these are basically git commands.
Without the glossiness of github, this is not that large of a project.
Submitters will do the rest through git.

I think, instead of tediously going through the PRs by hand, it is
wiser to set up some system like this.


Agreed.   +1000

Although if we go down the rabbit hole of building something like
github that might take a while.  For now prototyping using the github
pull methods might be a good proof of concept.  I may look into doing a
github pull request - GNATS (src) PR gateway if time allows.

Once again github pull request is the worst way of merging patches that exists.

We already have problem with ugly and inaccurate logs, such pull request will
make it even worse.

Making proper merge from github pull request it not that easy, you will need to
fetch pull request as custom branches and cherry-pick them. That is really not
convenient.

Probably a dozen lines of shell.


Actually no: add this to your git config file

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then all the pull request will be seen as branches you can safely cherry-pick.


Yes I know that...

-Alfred


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Montgomery-Smith, Stephen

On 01/24/2014 05:30 PM, Big Lebowski wrote:
 Hi everyone,
 
 I wanted to ask about the growing time of reaction to ports PR's - what is
 the problem? It seems to me, as a ports contributor, that this time is only
 growing, not shrinking, and there's no formal/automated procedures that
 would help in managing the issue.
 
 Today I found myself fighting with ezjail only to discover it has issues
 working on FreeBSD 10.0-R. Great, I thought, there must be something else,
 so I went to make the research. It appears there isnt much more, and the
 alternatives are qjail that seems to be quite dated and zjails, that's not
 in ports. Not long after looking into zjails, what seems to be a great
 tool, I found its port submission sits there since... September 2013. Now,
 given the fact the Docker is on mouth of everyone, and containers are
 getting a lot of attention, FreeBSD looks really bad with no tools to
 manage such great technology like Jails, especially when ezjail, unofficial
 industry standard to manage jails, is now broken and zjails waits to be
 accepted (or even rejected) for so much time.
 
 What is the problem? Isnt there enought commiters? Isnt there a automated
 PR handling procedure reminding commiters with relevant access about such
 submissions? Can we help? I hope to spark some discussion.
 
 Kind regards,
 B.

When I became a committer (about 2.5 years ago), I spent my first summer
going through PRs and committing them.  Prior to that I had submitted
many ports, and I had felt the same frustration as you.  And when I saw
that some PRs were rather old, I could feel their frustration.

However, since that summer of activity on my part, my work
responsibilities overtook me, and I simply didn't have the time to keep
committing other people's PRs.  I think I have done a pretty good job at
maintaining my ports, but I have been terrible at committing other
people's PRs.

So I have seen it from both sides, and I think both sides have an equal
right to feel frustrated.

I had noticed quite an influx of new committers at some point, and that
seemed like a great solution to me.  But each new committer also
requires mentoring for a while, and that is also an effort for someone.

I really don't know what to say.  Next summer, if I have time, I'll try
to get into doing another group of PRs.  When I did do PRs, I did try to
concentrate on the older ones, rather than picking up the newer ones.

The older ones probably require more effort.  Sometimes the PR has a
mistake in it, and that is why it was left alone.  Other times, it
requires a level of expertize that many committers simply don't have.
(For example, in my case, I have zero experience with jails, and it
would be a huge learning curve on my part to learn enough to responsibly
commit your port.)  Sometimes the port no longer works because of
changes to the system (e.g. staging or changes to the base system).

Anyway, I feel your pain, and I wish I had good answers.

Stephen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Ruslan Makhmatkhanov


Alfred Perlstein wrote on 25.01.2014 22:41:


Are any of these tools available on the other side?

Ie, for port submitters?

yes porttools for example, or some scripts inside Tools/scripts

regards,
Bapt

Is there a primer on using these tools?


/usr/ports/Tools/scripts/getpatch category/PR

--
Regards,
Ruslan

T.O.S. Of Reality
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 01/25/2014 05:43, Bernhard Fröhlich wrote:

With the scripts it should be possible to fetch the patch of a PR, apply
and commit it to your redports repository and do additional changes until
you are okay with it. What is still missing is a script that helps
committing the changes to the FreeBSD tree but it's really not that
complicated to write that.


This sounds like a very manual process again. Today it is already 
manual. This only automates the patching step.



be more specific and name the problem, if you mentioned it?

The raised concerns were that automatic build testing might result in less
testing on committer side. I agree that this might happen and automatic
build testing is only one part of what committers need to do. A huge
backlog and no response for months is definitely nothing we want.


But what exactly do committers test that can't be automated? Automatic 
system could install the port with dependencies into the blank 
installation, check syntax correctness, run 'lint' on it, verify that it 
installs/uninstalls cleanly and doesn't leave residue, etc etc. What is 
beyond that?
I am trying to understand, what would the general ports expert without 
the intimate knowledge of this particular package catch, that automated 
system won't be able to catch?


Yuri
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 5:28 PM, Yuri y...@rawbw.com wrote:

 On 01/25/2014 05:43, Bernhard Fröhlich wrote:

 With the scripts it should be possible to fetch the patch of a PR, apply
 and commit it to your redports repository and do additional changes until
 you are okay with it. What is still missing is a script that helps
 committing the changes to the FreeBSD tree but it's really not that
 complicated to write that.


 This sounds like a very manual process again. Today it is already manual.
 This only automates the patching step.


  be more specific and name the problem, if you mentioned it?

 The raised concerns were that automatic build testing might result in less
 testing on committer side. I agree that this might happen and automatic
 build testing is only one part of what committers need to do. A huge
 backlog and no response for months is definitely nothing we want.


 But what exactly do committers test that can't be automated? Automatic
 system could install the port with dependencies into the blank
 installation, check syntax correctness, run 'lint' on it, verify that it
 installs/uninstalls cleanly and doesn't leave residue, etc etc. What is
 beyond that?
 I am trying to understand, what would the general ports expert without the
 intimate knowledge of this particular package catch, that automated system
 won't be able to catch?


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



 Yuri




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


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.


Today all committers do for ports is running some generic tests by hand, 
like 'lint' with various flags. Install/uninstall/etc. No wonder this 
isn't very a rewarding activity, and committers probably perceive it as 
a necessary evil. The way how it is, it causes a waste of their time.


Yuri
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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



 Today all committers do for ports is running some generic tests by hand,
 like 'lint' with various flags. Install/uninstall/etc. No wonder this isn't
 very a rewarding activity, and committers probably perceive it as a
 necessary evil. The way how it is, it causes a waste of their time.


That's why I keep suggesting devel/aegis it does *EVERYTHING* git/git hub
does but all locally and has the added benefit that you can not change the
change set (aka port submission) until it has passed all 3 of the following
(you can turn all but the last two off at runtime and the first only needs
to build to pass at a min):

1. Develop change
   (To leave development it must build and pass *NEW* tests, this is where
the automation should go)

2. Review (this is where human eyes come in once all the automated tests
are passed)

3. Intergration make sure it plays well with others


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 01/25/2014 15:48, Aryeh Friedman wrote:

Git hup (or*ANY*  remote service for that matter) is a no go IMO


But both Debian and Fedora do this with automated remote testing, and 
they don't seem to complain.

How is our ports different in this respect?

Yuri
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 4:05 PM, Yuri wrote:

On 01/25/2014 15:48, Aryeh Friedman wrote:

Git hup (or*ANY*  remote service for that matter) is a no go IMO


But both Debian and Fedora do this with automated remote testing, and 
they don't seem to complain.

How is our ports different in this respect?


I don't get this either.

--
Alfred Perlstein

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 3:41 PM, Yuri 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.


Today all committers do for ports is running some generic tests by 
hand, like 'lint' with various flags. Install/uninstall/etc. No wonder 
this isn't very a rewarding activity, and committers probably perceive 
it as a necessary evil. The way how it is, it causes a waste of their 
time.



100% agree.

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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 
handle.


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.


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 9:04 PM, Alfred Perlstein alf...@freebsd.orgwrote:

 On 1/25/14 3:48 PM, Aryeh Friedman wrote:

 On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
 handle.


I am sorry your the one who does not get it.. not everything is either
testable remotely or should be... how do you propose to test device drivers
for example?


 Why?  Because then we offload the problem to another org.


With a hybrid cloud with most of the work being done on the
commiters/developers machine where is the overhead?



 The FreeBSD project should be about innovation in OS design, platform and
 software.  Ops work is bunk and just slows us down.


Sorry to tell you but the ability to handle a complex automated system is
one of the key things a OS must do... what better test then to build it
self?



 The more we can outsource the better we'll be.  (and what if that service
 blows up?  well we move on!  it's simple!)


What a total cop out if the service blows up fix it... or should we end up
with some of the real atrocities of linux like I/O times that are
impossible (claiming it takes less then a second to copy 10GB for
example)... note the above timing issue it makes resource scheduling next
to impossible in a distributed environment if you get different timings for
the same operation... bottom line writing and maintain a OS *IS* about
operations and nothing else.


 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.


I never said our selves it is outsourced to the developer/maintainer with
100% automated stuff... once I am doing with the next small version of
petitecloud I will post the 6 line script we use to test the port
(including cranking up a few vm's)... have fun doing that anywhere else


 -Alfred




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

I never said our selves it is outsourced to the developer/maintainer with
 100% automated stuff... once I am doing with the next small version of
 petitecloud I will post the 6 line script we use to test the port
 (including cranking up a few vm's)... have fun doing that anywhere else


Got bored here is the non-cleaned up version (it is for devel/cook and not
the shell):

cook-blank/deploy-remoteinstall: cook-blank/scrap-all
{
echo Remote install;

remoteIp=aryeh@10.0.10.30;
ssh [remoteIp] sudo rm -rf '*';
scp scrap/predeploy/port-[realversion]-[user].tar.gz
[remoteIp]':'port.tar.gz;
scp scrap/predeploy/src-[fullproject].tar.gz
[remoteIp]':'src-[fullproject].tar.gz;
ssh [remoteIp] sudo mv src-[fullproject].tar.gz
/usr/ports/distfiles;
ssh [remoteIp] sudo rm -rf /usr/ports/emulators/petitecloud;
ssh [remoteIp] sudo tar fvx port.tar.gz;
ssh [remoteIp] sudo make deinstall clean install;
}

Doesn't that look a lot easier then what you where talking about?
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Jim Ohlstein


Hello,

On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@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
handle.

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.


I've read all 60 or so messages in this thread and there really are two 
related but distinct issues here.


The thread title is What is the problem with ports PR reaction 
delays?. This has meandered into a philosophical debate about who knows 
what and who knows squat about version control systems, whether we need 
to maintain certain requirements, testing ports, etc.


I like the KISS approach myself. This can be boiled down to those two 
issues, one of which is a symptom of the other. Arguing and debating 
over a long term solution to the OP's question does nothing to solve the 
problem in the short to intermediate term. There are 1680 current ports 
related PR's at this moment.


As we all know, the committers are volunteers, mostly with real jobs and 
real lives and they obviously cannot keep up with the current load. The 
short to medium term solution for that is more committers. I'll add my 
name to the list of those who are willing to step in and help to clean 
up the mess. I'm certain that if a request went out, there would be many 
who are more qualified than I.


At the same time, a group of interested individuals should offer input 
to the folks who already are looking at changing the bug reporting 
system away from gnats - 
https://wiki.freebsd.org/Bugtracking/BugRelocationPlan. Doing it in one 
fell swoop might make sense. It's ripping off the bandaid but I'd 
rather do it only once myself.


What does *not* make sense is a new port for what might be a very useful 
tool waiting since September for someone to look at it. Arguing over git 
and subversion et alia does nothing to fix that. As they say on the ESPN 
NFL pregame show, C'mon man!.


--
Jim Ohlstein
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?


 I like the KISS approach myself. This can be boiled down to those two
 issues, one of which is a symptom of the other. Arguing and debating over a
 long term solution to the OP's question does nothing to solve the problem
 in the short to intermediate term. There are 1680 current ports related
 PR's at this moment.


The reason for the whole tangent was the observation that large number of
the pending PR's are likely to fail one or more *BASIC*  tests and setting
stuff up to run those tests is trivial (like I said I voluneteer to do
it)... the other main thread there was that some of the *IDEAS* of SCM can
borrowed and incorporated into manual procedures (such as requiring a
successful build before a human will look at it) the other one is a more
formalized workflow such as the one that aegis enforces if just the
first is done I think half the PR's can be cleared out immediately and if
both then 80% can be cleared out within a few weeks


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-25 Thread Jim Ohlstein

Hello,

On 1/25/14, 10:33 PM, Aryeh Friedman wrote:

I like the KISS approach myself. This can be boiled down to those
two issues, one of which is a symptom of the other. Arguing and
debating over a long term solution to the OP's question does nothing
to solve the problem in the short to intermediate term. There are
1680 current ports related PR's at this moment.

The reason for the whole tangent was the observation that large number
of the pending PR's are likely to fail one or more *BASIC* tests and
setting stuff up to run those tests is trivial (like I said I voluneteer
to do it)... the other main thread there was that some of the *IDEAS* of
SCM can borrowed and incorporated into manual procedures (such as
requiring a successful build before a human will look at it) the other
one is a more formalized workflow such as the one that aegis
enforces if just the first is done I think half the PR's can be
cleared out immediately and if both then 80% can be cleared out within a
few weeks

None of those *IDEAS* solve the current problem. The personal argument
solves less than nothing. Debate is cool. Telling people they don't know
anything is not.

Your statement looks to be pure supposition to me. On
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=portsseverity=priority=class=state=sort=nonetext=responsible=multitext=originator=release=
the vast majority of them are not color coded beyond white which simply
means open. Many have not even been assigned. Only a comparatively
small number are analyzed, [awaiting] feedback, patched,
suspended, or closed. In other words no one knows how many will
fail. The ones that are a decade old probably will. Those from the last
few months, the majority, are anyone's guess since they haven't even
been reviewed. That is unless you have some hard data to back up your
claim about those percentages.

As for changing the workflow, again, that's not a short-term solution,
and probably not even a medium-term answer. The answer is to get them
looked at and stop having a pissing contest over who knows more and who
knows less. *THAT* solves nothing.

Peace out.

--
Jim Ohlstein

Never argue with a fool, onlookers may not be able to tell the
difference. - Mark Twain

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

What is the problem with ports PR reaction delays?

Hi everyone,

I wanted to ask about the growing time of reaction to ports PR's - what is
the problem? It seems to me, as a ports contributor, that this time is only
growing, not shrinking, and there's no formal/automated procedures that
would help in managing the issue.

Today I found myself fighting with ezjail only to discover it has issues
working on FreeBSD 10.0-R. Great, I thought, there must be something else,
so I went to make the research. It appears there isnt much more, and the
alternatives are qjail that seems to be quite dated and zjails, that's not
in ports. Not long after looking into zjails, what seems to be a great
tool, I found its port submission sits there since... September 2013. Now,
given the fact the Docker is on mouth of everyone, and containers are
getting a lot of attention, FreeBSD looks really bad with no tools to
manage such great technology like Jails, especially when ezjail, unofficial
industry standard to manage jails, is now broken and zjails waits to be
accepted (or even rejected) for so much time.

What is the problem? Isnt there enought commiters? Isnt there a automated
PR handling procedure reminding commiters with relevant access about such
submissions? Can we help? I hope to spark some discussion.

Kind regards,
B.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-24 Thread John Marino

On 1/25/2014 00:30, Big Lebowski wrote:
 Hi everyone,
 
 I wanted to ask about the growing time of reaction to ports PR's - what is
 the problem? It seems to me, as a ports contributor, that this time is only
 growing, not shrinking, and there's no formal/automated procedures that
 would help in managing the issue.
 
 What is the problem? 

Seriously?  You did all that research and didn't notice this?
query all open ports PRS: 1705 problems total.

Short answer: Sheer number of PRs.

 Isnt there enought commiters?

Well, at least there are more PRs than people closing PRs.  Not all
committers deal with PRs.  Getting a commit bit does not obligate you to
process PRs.  If there's a PR already on a port a committer has interest
in fixing, then he/she will probably process the PR while they are there.

  Isnt there a automated
 PR handling procedure reminding commiters with relevant access about such
 submissions? Can we help? I hope to spark some discussion.

Of course there is.  People get reminded about assigned PRs constantly.
 You think a computer message will make somebody work faster if they
didn't forget about it (iow they are aware and actively decided not to
deal with it yet).

I would have thought the situation is kind of obvious.  There are lots
of PRs, nobody is paid to process them, there are no teams dedicated to
new ports, lots of PRs are stuck because their non-freebsd.org
maintainers are MIA or abandoned their emails and nobody is going to
touch a PR in feedback, etc, etc.  Finally, some committers are pretty
sloppy at closing complete/obsolete PRs.

When people get paid to do it, I think the situation will improve. :)

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-24 Thread Aryeh Friedman

On Fri, Jan 24, 2014 at 6:30 PM, Big Lebowski spankthes...@gmail.comwrote:

 Hi everyone,

 I wanted to ask about the growing time of reaction to ports PR's - what is
 the problem? It seems to me, as a ports contributor, that this time is only
 growing, not shrinking, and there's no formal/automated procedures that
 would help in managing the issue.

 Today I found myself fighting with ezjail only to discover it has issues
 working on FreeBSD 10.0-R. Great, I thought, there must be something else,
 so I went to make the research. It appears there isnt much more, and the
 alternatives are qjail that seems to be quite dated and zjails, that's not
 in ports. Not long after looking into zjails, what seems to be a great
 tool, I found its port submission sits there since... September 2013. Now,
 given the fact the Docker is on mouth of everyone, and containers are
 getting a lot of attention, FreeBSD looks really bad with no tools to
 manage such great technology like Jails, especially when ezjail, unofficial
 industry standard to manage jails, is now broken and zjails waits to be
 accepted (or even rejected) for so much time.


Why not test on a VM instead of a jail it seems this is a even more
accurate test because you can run bare metal installs (I have run to some
ports [including some of my own]) that worked with jail/tinderbox but
failed a full bare metal install.   Take a look at -virtualization@ for
ideas, the proposed handbook entry on virtualization (
http://www.petitecloud.org) or just use a front end like petitecloud (yes
yet an other port waiting for comitting [one this one there are some bugs
though])

What is the problem? Isnt there enought commiters? Isnt there a automated
 PR handling procedure reminding commiters with relevant access about such
 submissions? Can we help? I hope to spark some discussion.


I have made a couple of scripts for automated this for specific ports but
not for all (the VM test method)... if you want I can post them (they are
high;y specific to installing the petitecloud port though)

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 12:45 AM, Aryeh Friedman
aryeh.fried...@gmail.comwrote:




 On Fri, Jan 24, 2014 at 6:30 PM, Big Lebowski spankthes...@gmail.comwrote:

 Hi everyone,

 I wanted to ask about the growing time of reaction to ports PR's - what is
 the problem? It seems to me, as a ports contributor, that this time is
 only
 growing, not shrinking, and there's no formal/automated procedures that
 would help in managing the issue.

 Today I found myself fighting with ezjail only to discover it has issues
 working on FreeBSD 10.0-R. Great, I thought, there must be something else,
 so I went to make the research. It appears there isnt much more, and the
 alternatives are qjail that seems to be quite dated and zjails, that's not
 in ports. Not long after looking into zjails, what seems to be a great
 tool, I found its port submission sits there since... September 2013. Now,
 given the fact the Docker is on mouth of everyone, and containers are
 getting a lot of attention, FreeBSD looks really bad with no tools to
 manage such great technology like Jails, especially when ezjail,
 unofficial
 industry standard to manage jails, is now broken and zjails waits to be
 accepted (or even rejected) for so much time.


 Why not test on a VM instead of a jail it seems this is a even more
 accurate test because you can run bare metal installs (I have run to some
 ports [including some of my own]) that worked with jail/tinderbox but
 failed a full bare metal install.   Take a look at -virtualization@ for
 ideas, the proposed handbook entry on virtualization (
 http://www.petitecloud.org) or just use a front end like petitecloud (yes
 yet an other port waiting for comitting [one this one there are some bugs
 though])

 What is the problem? Isnt there enought commiters? Isnt there a automated
 PR handling procedure reminding commiters with relevant access about such
 submissions? Can we help? I hope to spark some discussion.


 I have made a couple of scripts for automated this for specific ports but
 not for all (the VM test method)... if you want I can post them (they are
 high;y specific to installing the petitecloud port though)


 --
 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


I think you've got me wrong - I am following freebsd-virtualization list
very closely, and the matter I've touched here is not my doubt on which
technology I should use, but rather a complaint on the state of jails
related tools directly leading to the delays in handling of ports related
PR's. I know the technology alternatives, I am decided to jails for a
reason, and I also know your work on the web interface focusing on bhyve,
but its not about it.

B.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

On Sat, Jan 25, 2014 at 12:41 AM, John Marino freebsd.cont...@marino.stwrote:

 On 1/25/2014 00:30, Big Lebowski wrote:
  Hi everyone,
 
  I wanted to ask about the growing time of reaction to ports PR's - what
 is
  the problem? It seems to me, as a ports contributor, that this time is
 only
  growing, not shrinking, and there's no formal/automated procedures that
  would help in managing the issue.
 
  What is the problem?

 Seriously?  You did all that research and didn't notice this?
 query all open ports PRS: 1705 problems total.

 Short answer: Sheer number of PRs.


I did, in fact, and this is not the problem, this is the symptom of the
problem.



  Isnt there enought commiters?

 Well, at least there are more PRs than people closing PRs.  Not all
 committers deal with PRs.  Getting a commit bit does not obligate you to
 process PRs.  If there's a PR already on a port a committer has interest
 in fixing, then he/she will probably process the PR while they are there.

   Isnt there a automated
  PR handling procedure reminding commiters with relevant access about such
  submissions? Can we help? I hope to spark some discussion.

 Of course there is.  People get reminded about assigned PRs constantly.
  You think a computer message will make somebody work faster if they
 didn't forget about it (iow they are aware and actively decided not to
 deal with it yet).

 I would have thought the situation is kind of obvious.  There are lots
 of PRs, nobody is paid to process them, there are no teams dedicated to
 new ports


Perhaps there could be? Or some commiters who would assess if the PR can be
handled easily or it needs a more experienced eye to look at it?


 , lots of PRs are stuck because their non-freebsd.org
 maintainers are MIA or abandoned their emails and nobody is going to


Shouldnt those be invalidated and closed to reduce the workload illusion
that tends to set off people from doing work?


 touch a PR in feedback, etc, etc.  Finally, some committers are pretty
 sloppy at closing complete/obsolete PRs.

 When people get paid to do it, I think the situation will improve. :)


Great, then perhaps FreeBSD deserves dedicated, paid commiter to handle
that situation? After all, we're donating money to the project, and if
there's general consensus this is a problem that needs to be fixed and this
is the only way to do it, then perhaps something can be done about it?



 John
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

2014-01-24 Thread John Marino

On 1/25/2014 01:03, Big Lebowski wrote:
 On Sat, Jan 25, 2014 at 12:41 AM, John Marino 
 freebsd.cont...@marino.stwrote:
 
 On 1/25/2014 00:30, Big Lebowski wrote:
 Hi everyone,

 I wanted to ask about the growing time of reaction to ports PR's - what
 is
 the problem? It seems to me, as a ports contributor, that this time is
 only
 growing, not shrinking, and there's no formal/automated procedures that
 would help in managing the issue.

 What is the problem?

 Seriously?  You did all that research and didn't notice this?
 query all open ports PRS: 1705 problems total.

 Short answer: Sheer number of PRs.

 
 I did, in fact, and this is not the problem, this is the symptom of the
 problem.

No, it's not.  PRs are getting closed, all the time, every day.  But PRs
are coming in faster than they are getting closed.  A couple of days
ago, the number of open PRs was down to 1660.

You can say the solution is to increase the rate of PR closing.  I could
counter with not allowing any new PRs to be submitted.  Both would solve
the problem, and my way is easier to implement. :)


 I would have thought the situation is kind of obvious.  There are lots
 of PRs, nobody is paid to process them, there are no teams dedicated to
 new ports
  
 Perhaps there could be? Or some commiters who would assess if the PR can be
 handled easily or it needs a more experienced eye to look at it?
 

Timeless question: How does one force a volunteer to do anything?
Answer: You can't.


 , lots of PRs are stuck because their non-freebsd.org
 maintainers are MIA or abandoned their emails and nobody is going to

 
 Shouldnt those be invalidated and closed to reduce the workload illusion
 that tends to set off people from doing work?

Yes.
Now, who is going to do it?
And after you select him or her, how do you force them to do it?



 touch a PR in feedback, etc, etc.  Finally, some committers are pretty
 sloppy at closing complete/obsolete PRs.

 When people get paid to do it, I think the situation will improve. :)

 
 Great, then perhaps FreeBSD deserves dedicated, paid commiter to handle
 that situation? After all, we're donating money to the project, and if
 there's general consensus this is a problem that needs to be fixed and this
 is the only way to do it, then perhaps something can be done about it?


I don't control FreeBSD Foundation funds in any way.
Having a full time paid person doing PR triage would put a huge dent in
the backlog.  But we're just wishing, right?  There aren't many paid
positions and those don't do clerical work like trouble tickets.

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?