FAQ
As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?

Thanks,
Todd

Search Discussions

  • Reini Urban at Jun 7, 2012 at 9:16 pm

    On Thu, Jun 7, 2012 at 2:36 PM, Todd Rinaldo wrote:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?
    As I see it, almost none of the affected managers have information on
    that, only Craig Berry for his "frequent" vms releases. (sorry, just
    joking)
    No activeperl, mingw, debian, redhat, macports, bsd, cygwin, ...
    release managers can see what patches should be or will be backported
    to their maintainance branches, nor can they vote on it.

    On the other way round there is also not lots of information flowing.
    At least windows, debian and cygwin try
    to get their patches into blead, from time to time.

    And I see no way how that can be improved.
    --
    Reini Urban
  • Craig A. Berry at Jun 7, 2012 at 11:57 pm

    On Thu, Jun 7, 2012 at 4:16 PM, Reini Urban wrote:
    On Thu, Jun 7, 2012 at 2:36 PM, Todd Rinaldo wrote:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?
    It's a good question. I don't know the answer, but ISTR both Jesse
    and Ricardo asking for folks to find ways to make it more public,
    scalable, robust, etc. As Leon has now posted, the source code is
    there to be fiddled with.

    But remember, cherrymaint was a nifty, quick hack to work around the
    absence of a maint pumpking. More visibility would be a very good
    thing, but there would need to be other changes as well in order to
    manage additional input. IMO, we need not only a way for more people
    to say "please get patch 123 into the next release," but also (and
    even more importantly), a way for people to say, "Assign patch 123 to
    me; I'll test it on versions I, J, K of compiler/platforms X, Y, Z in
    configurations A, B, C, and while I'm there I'll read and understand
    what it's doing and determine whether it preserves binary
    compatibility, and has adequate test coverage, and I'll step through
    it in gdb to see if it's really doing what we're saying it's doing,
    and slam it against valgrind to see what breaks, and I'll weigh the
    benefits against the risks for putting it in maint, etc."

    My point is that there is more than one definition of "voting up" a
    commit. There is nothing wrong with the first (easier) kind in and of
    itself. I hope we find ways to make lots more of the second kind
    easier too because that's the real impediment to more ambitious maint
    releases IMO.
    As I see it, almost none of the affected managers have information on
    that, only Craig Berry for his "frequent" vms releases. (sorry, just
    joking)
    I don't get the joke but I'm also not bothered by it; every source
    tarball has what's needed to build on VMS, so the frequency is the
    same as every other platform.
    No activeperl, mingw, debian, redhat, macports, bsd, cygwin, ...
    release managers can see what patches should be or will be backported
    to their maintainance branches, nor can they vote on it.

    On the other way round there is also not lots of information flowing.
    At least windows, debian and cygwin try
    to get their patches into blead, from time to time.
    I don't understand this at all. Steve Hay committed a boatload of
    Windows patches today. There are rather a lot of committers -- the
    list is publicly available here:

    <http://perl5.git.perl.org/committers.cgi>

    And I'm fairly certain some of those 45 folks work for ActiveState or
    one of the Linux distros, and of course there are quite a few notable
    CPAN authors on the list. booking.com has rather assertively placed
    itself in the middle of things with both people and money, which is a
    rather nice example of enlightened self-interest. As far as I know,
    there are no employees of HP/Oracle/Apple/IBM/Microsoft on the list,
    yet Perl works just fine on many (though not all) of the operating
    systems produced by those companies, and quite a few people spend
    effort getting things working even on platforms they don't normally
    use.

    Plus every release announcement contains a list of contributors, many
    of whom are not committers, so clearly a lot of good work is getting
    done without any official or unofficial representation. Ricardo and
    his predecessors have been harping on increased visibility for some
    time; it's yet another thankless aspect of cat herding and it's one of
    those things that will never be perfect but there are certainly no
    platform or distribution prejudices that I can see.
    And I see no way how that can be improved.
    Saying things can't be improved is likely not going to help get them
    improved. I'm probably not improving things by saying something so
    obvious :-(.
  • Reini Urban at Jun 10, 2012 at 9:39 pm
    Trying to improve now:

    I analyzed the list of committers since it is now public, with their
    commits, vs the non-committers authors with their fields of expertise.
    And I see no way how that can be improved.
    Saying things can't be improved is likely not going to help get them
    improved.  I'm probably not improving things by saying something so
    obvious :-(.
    $ perl -ne'next if $. < 3; chomp;$n=`git log --oneline --author "$_" |
    wc -l`;chomp $n;print "$n\t$_\n";' Porting/committers| sort -rn
    Porting/committers.commits
    # With 3 non-found names handled manually.

    5989 Nicholas Clark
    3019 Rafael Garcia-Suarez
    2638 Father Chrysostomos
    2085 Karl Williamson
    884 Craig A. Berry
    725 Steve Peters
    709 Steve Hay
    583+578 Dave Mitchell
    550 Florian Ragwitz
    485 H.Merijn Brand
    480 Jesse Vincent
    417 Chip Salzenberg
    350 Steffen Mueller
    321 Yves Orton
    312 David Golden
    290 Jan Dubois
    285 Andy Dougherty
    272 Marcus Holland-Moritz
    266 Gisle Aas
    261 Abigail
    224 Ricardo Signes
    207 Zefram
    200 Abhijit Menon-Sen
    171 Vincent Pit
    169 Yitzchak Scott-Thoennes
    151 Tony Cook
    136 Ævar Arnfjörð Bjarmason
    120 Leon Brocard
    116 Robin Houston
    109 brian d foy
    105 Dave Rolsky
    100 Chris 'Bingos' Williams
    98 Slaven Rezic
    96 Tim Bunce
    66 Graham Barr
    52 Max Maischein
    34 Josh ben Jore
    32 Leon Timmermans
    28 George Greer
    23 Stevan Little
    20 Tatsuhiko Miyagawa
    17 Matt S. Trout
    11 Dominic Hargreaves
    4 Philippe Bruhat
    1 Jesse Luehrs

    vs non-committers + unique expertise
    (stopped lower than 10 as the list is huge):

    $ git log --pretty=format:%an > Porting/authors
    $ sort < Porting/authors | uniq -c|sort -rn

    7863 Jarkko Hietaniemi
    2846 Gurusamy Sarathy
    732 Perl 5 Porters
    484 Ilya Zakharevich
    397 Michael G. Schwern (eumm)
    306 Jerry D. Hedden (threads)
    292 Hugo van der Sanden
    254 Malcolm Beattie (compiler)
    217 Artur Bergman
    202 Robin Barker
    199 Andy Lester
    184 Peter Prymmers
    160 Paul Marquess
    151 Tony Cook (windows)
    140 Charles Bailey
    131 Larry Wall
    131 Brian Fraser (utf8 names)
    120 Leon Brocard
    114 John E. Malmberg (vms)
    110 Jim Cromie
    110 Andreas König (pause)
    109 Reini Urban (cygwin, compiler)
    109 brian d foy
    99 SADAHIRO Tomoyuki (unicode)
    98 Slaven Rezic
    96 Doug MacEachern
    94 James E. Keenan
    91 Mark-Jason Dominus
    88 Simon Cozens
    88 Gerard Goossen
    82 Tels
    82 Stephen McCamant (B::Concise)
    80 Vadim Konovalov
    78 Jos I. Boumans
    75 Philip Newton
    75 Adrian M. Enache
    72 Dominic Dunlop
    71 Stas Bekman
    71 chromatic
    70 John Peacock
    69 Paul Green
    68 Hans Mulder
    65 Spider Boardman
    63 Marc Green
    62 Ben Morrow
    61 Mike Guy
    56 Roderick Schertler
    48 Tom Christiansen (pod)
    48 Rick Delaney
    48 Michael Stevens
    48 Abe Timmerman
    41 David Leadbeater
    41 Bram
    40 Charles Lane
    38 Michael G Schwern
    37 Shlomi Fish
    37 Paul "LeoNerd" Evans
    37 Dan Kogai
    36 Alan Burlison
    35 Jonathan Stowe
    35 Brendan O'Dea
    35 Benjamin Sugars
    34 Tim Jenness
    34 Paul Johnson
    34 Niko Tyni (debian)
    34 M. J. T. Guy
    33 Norton T. Allen
    33 Eric Brine
    32 Jeff Pinyan
    32 Audrey Tang
    31 Elizabeth Mattijsen
    31 Alexey Tourbin
    30 Richard Soderberg
    30 Radu Greab
    30 John Malmberg
    30 jkeenan
    29 Sébastien Aperghis-Tramoni
    29 Gerrit P. Haase
    29 David Landgren
    29 David Dyck
    28 John P. Linderman
    27 Vishal Bhatia
    27 Steven Schubiger
    27 Prymmer/Kahn
    27 Peter John Acklam
    27 Lupe Christoph
    26 Mattia Barbon
    26 Dan Sugalski
    25 Wolfgang Laun
    25 Ronald J. Kimball
    25 Paul Fenwick
    25 Johan Vromans
    25 Chris Nandor
    24 Tom Phoenix
    24 Robert Spier
    24 Michael Witten
    24 Jeffrey Friedl
    23 Nikola Knezevic
    23 Casey West
    23 Andreas Koenig
    22 Peter J. Acklam) (via RT
    22 Kurt D. Starsinic
    21 Rainer Tammer
    21 Laszlo Molnar
    20 Peter Scott
    19 Todd Rinaldo
    19 Richard Foley
    19 M.J.T. Guy
    19 Barrie Slaymaker
    18 Moritz Lenz
    18 Brandon Black
    17 Ton Hospel
    17 Tassilo von Parseval
    17 Larry W. Virden
    17 Joshua Pritikin
    17 Gabor Szabo
    17 Andreas J. Koenig
    17 Alex Vandiver
    16 Douglas Lankshear
    16 Daniel S. Lewart
    16 Brad Gilbert
    16 Adriano Ferreira
    15 Todd C. Miller
    15 Russ Allbery
    15 Daniel Chetlin
    15 Anton Berezin
    14 Salvador Fandiño
    14 John Tobey
    14 Jeff Okamoto
    14 Hallvard B Furuseth
    14 Ben Tilly
    14 Anno Siegel
    14 Alexandr Ciornii
    13 Matt Kraai
    13 Fifer, Eric
    13 Bo Lindbergh
    12 Tom Hukins
    12 John L. Allen
    12 James Mastros
    12 Duke Leto
    12 Casey R. Tweten
    11 Stephen P. Potter
    11 Roca, Ignasi
    11 Peter Dintelmann
    11 Olaf Flebbe
    11 Karl
    11 Inaba Hiroto
    11 Fergal Daly
    11 Curtis Jewell
    10 Yuval Kogman
    10 Shawn M Moore
    10 Renee Baecker
    10 Peter J. Acklam
    10 Norbert Pueschel
    10 Nathan Torkington
    10 Leo Lapworth
    10 Ken Williams
    10 Jens Hamisch
    10 David Nicol
    10 Adam Russell

    How e.g. did a Dominic Hargreaves, Philippe Bruhat or Jesse Luehrs get
    on the list, without any public discussion? This looks pretty
    arbitrary to me. On parrot there is at least a public process.
  • Aristotle Pagaltzis at Jun 11, 2012 at 2:24 am

    * Reini Urban [2012-06-10 23:40]:
    I analyzed the list of committers since it is now public, with their
    commits, vs the non-committers authors with their fields of expertise.
    You analysed the list of persons who have created commit objects in the
    perl.git repository.

    You did not analyse the list of persons who have push access to
    perl5.git.perl.org.
    How e.g. did a Dominic Hargreaves, Philippe Bruhat or Jesse Luehrs get
    on the list
    Git is distributed. You can have commit access to one Git clone of the
    same project but not another. Just because Dominic, Philippe or Jesse
    created those commit objects in *some* clone of perl.git does not mean
    they pushed those commits to perl5.git.perl.org themselves. Someone with
    push access could have pulled these commits from them from anywhere and
    then pushed to perl5.git.perl.org, without first rebasing or amending
    the commits, in which case Git sees no reason to rewrite them and does
    not (and cannot, because the SHA1 would change) record the pusher’s name
    as the committer. Which is correct anyway, because pushing commits does
    not make you their committer.

    If you did want to analyse who is responsible for those commits getting
    into the central perl.git, you would have to analyse the reflogs in the
    repo on perl5.git.perl.org – assuming the commits didn’t get pushed to
    a topic branch first, because when the branch is deleted then so is its
    reflog. So if you wanted a paper trail on this you would have to devise
    some machinery to archive (and probably sign) the reflogs forever.
    without any public discussion? This looks pretty arbitrary to me. On
    parrot there is at least a public process.
    To my knowledge has never been any kind of public process for commit or
    push access to the perl repository, nor have the porters ever committed
    to having any process in the open. Unlike many other parts of the Perl
    development process I’m not aware of any concerns about the viability of
    the push access policy now or in the past either.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Jesse Luehrs at Jun 11, 2012 at 2:31 am

    On Mon, Jun 11, 2012 at 04:24:01AM +0200, Aristotle Pagaltzis wrote:
    * Reini Urban [2012-06-10 23:40]:
    I analyzed the list of committers since it is now public, with their
    commits, vs the non-committers authors with their fields of expertise.
    You analysed the list of persons who have created commit objects in the
    perl.git repository.

    You did not analyse the list of persons who have push access to
    perl5.git.perl.org.
    That actually is the list of people with push access, it can be seen at
    http://perl5.git.perl.org/committers.cgi
    How e.g. did a Dominic Hargreaves, Philippe Bruhat or Jesse Luehrs
    get on the list without any public discussion? This looks pretty
    arbitrary to me. On parrot there is at least a public process.
    To my knowledge has never been any kind of public process for commit or
    push access to the perl repository, nor have the porters ever committed
    to having any process in the open. Unlike many other parts of the Perl
    development process I’m not aware of any concerns about the viability of
    the push access policy now or in the past either.
    For what it's worth, I have commit access because I am in charge of the
    5.17.1 release. I really don't see a point in arguing about whether
    various people deserve commit access or not, in the absence of any
    actual problems though - have Philippe or Dominic committed anything you
    disagree with? If not, why are you even bringing this up?

    -doy
  • Aristotle Pagaltzis at Jun 11, 2012 at 2:38 am

    * Jesse Luehrs [2012-06-11 04:35]:
    I really don't see a point in arguing about whether various people
    deserve commit access or not, in the absence of any actual problems
    Same here.
  • Leon Timmermans at Jun 7, 2012 at 9:51 pm

    On Thu, Jun 7, 2012 at 9:36 PM, Todd Rinaldo wrote:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?
    The software we use for tracking it is lacking some much wanted
    features, but if you want to add them you can find it on github
    (https://github.com/rgs/cherrymaint).

    Leon
  • Father Chrysostomos at Jun 10, 2012 at 7:47 pm

    Todd Rinaldo:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?

    It’s not publicly viewable. But I had a look, and the only commit that has been voted on since 5.16 is 5c0877f, which has had one vote from Craig Berry.
  • Dominic Hargreaves at Jun 10, 2012 at 8:04 pm

    On Sun, Jun 10, 2012 at 12:47:00PM -0700, Father Chrysostomos wrote:

    Todd Rinaldo:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?

    It’s not publicly viewable. But I had a look, and the only commit that has been voted on since 5.16 is 5c0877f, which has had one vote from Craig Berry.
    Incidentally, it seems that cherrymaint doesn't know about maint-5.16
    yet, so 5c0877f is being requested for maint-5.14 only as far as
    cherrymaint is concerned.

    Presumably it should be taught about 5.16?

    Related: are there likely to be any more 5.14.x releases? There are
    currently 12 'approved' commits for maint-5.14 together with the 15
    commits already in maint-5.14.

    Cheers,
    Dominic.

    --
    Dominic Hargreaves | http://www.larted.org.uk/~dom/
    PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
  • Dominic Hargreaves at Jun 10, 2012 at 8:22 pm

    On Sun, Jun 10, 2012 at 09:04:27PM +0100, Dominic Hargreaves wrote:
    On Sun, Jun 10, 2012 at 12:47:00PM -0700, Father Chrysostomos wrote:

    Todd Rinaldo:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?

    It’s not publicly viewable. But I had a look, and the only commit that has been voted on since 5.16 is 5c0877f, which has had one vote from Craig Berry.
    Incidentally, it seems that cherrymaint doesn't know about maint-5.16
    yet, so 5c0877f is being requested for maint-5.14 only as far as
    cherrymaint is concerned.

    Presumably it should be taught about 5.16?

    Related: are there likely to be any more 5.14.x releases? There are
    currently 12 'approved' commits for maint-5.14 together with the 15
    commits already in maint-5.14.
    Ah, and I suspect that this boils down to the dilemma reached
    in the thread starting

    <http://www.nntp.perl.org/group/perl.perl5.porters/2012/03/msg184833.html>

    RT was mentioned briefly. Having a maint queue or queues (one per
    branch) seems like a good way forward, continuing to use cherrymaint to
    keep track of votes. That way necessary rebasing/assessment of
    dependencies could be tracked in RT tickets, together with pointers
    of smoking people have done, justifications and other commentary.

    Would setting up those new queue or queues (if only one queue, a
    custom field would be required as well) be possible if people thought
    it was a good idea?

    --
    Dominic Hargreaves | http://www.larted.org.uk/~dom/
    PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
  • Craig A. Berry at Jun 10, 2012 at 10:03 pm

    On Sun, Jun 10, 2012 at 3:04 PM, Dominic Hargreaves wrote:

    Incidentally, it seems that cherrymaint doesn't know about maint-5.16
    yet, so 5c0877f is being requested for maint-5.14 only as far as
    cherrymaint is concerned.
    I noticed that after I requested it. It should be applicable for
    maint-5.14 as well maint-5.16, but I'll verify that.
    Presumably it should be taught about 5.16?
    Yes, and maint-5.16 needs to be added to the list of branches
    available via rsync as well. There is maintenance work to doing
    maintenance releases. I think I know what to do about rsync; I don't
    know what's involved in maintaining cherrymaint.
    Related: are there likely to be any more 5.14.x releases? There are
    currently 12 'approved' commits for maint-5.14 together with the 15
    commits already in maint-5.14.
    I think it's up to Ricardo and unfortunately would mean dividing his
    time between two maint branches and cat herding blead.
  • Dominic Hargreaves at Jun 10, 2012 at 10:27 pm

    On Sun, Jun 10, 2012 at 05:02:57PM -0500, Craig A. Berry wrote:
    On Sun, Jun 10, 2012 at 3:04 PM, Dominic Hargreaves wrote:

    Incidentally, it seems that cherrymaint doesn't know about maint-5.16
    yet, so 5c0877f is being requested for maint-5.14 only as far as
    cherrymaint is concerned.
    I noticed that after I requested it. It should be applicable for
    maint-5.14 as well maint-5.16, but I'll verify that.
    Presumably it should be taught about 5.16?
    Yes, and maint-5.16 needs to be added to the list of branches
    available via rsync as well. There is maintenance work to doing
    maintenance releases. I think I know what to do about rsync; I don't
    know what's involved in maintaining cherrymaint.
    I took a wild guess and submitted a pull request for an updated
    config file:

    https://github.com/rgs/cherrymaint/pull/3

    --
    Dominic Hargreaves | http://www.larted.org.uk/~dom/
    PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
  • Rafael Garcia-Suarez at Jun 11, 2012 at 10:06 am

    On 11 June 2012 00:27, Dominic Hargreaves wrote:
    On Sun, Jun 10, 2012 at 05:02:57PM -0500, Craig A. Berry wrote:
    On Sun, Jun 10, 2012 at 3:04 PM, Dominic Hargreaves wrote:

    Incidentally, it seems that cherrymaint doesn't know about maint-5.16
    yet, so 5c0877f is being requested for maint-5.14 only as far as
    cherrymaint is concerned.
    I noticed that after I requested it.  It should be applicable for
    maint-5.14 as well maint-5.16, but I'll verify that.
    Presumably it should be taught about 5.16?
    Yes, and maint-5.16 needs to be added to the list of branches
    available via rsync as well.  There is maintenance work to doing
    maintenance releases.  I think I know what to do about rsync; I don't
    know what's involved in maintaining cherrymaint.
    I took a wild guess and submitted a pull request for an updated
    config file:

    https://github.com/rgs/cherrymaint/pull/3
    Thanks ! I overlooked that. Merged and deployed now.

    During the Paris QA hackathon I added a read-only view to cherrymaint
    (unauthenticated). The functionality is there, it just needs now to
    run on a public port. I'll have a look at that with Dennis.
  • Reini Urban at Jun 10, 2012 at 8:16 pm

    On Sun, Jun 10, 2012 at 2:47 PM, Father Chrysostomos wrote:
    Todd Rinaldo:
    As I understand it, one has to have a pemit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?

    It’s not publicly viewable.  But I had a look, and the only commit that has been voted on since 5.16 is 5c0877f, which has had one vote from Craig Berry.
    See, that's the problem. The committers do releases on incomplete data
    since nobody of them looks at the downstream release managers
    problems.
    Craig Berry is besides Jan Dubois the only one, and they only care
    about their areas. What about linux maint releases e.g.? I believe
    some might care about debian at least.

    There were enough problems outlined and voted on p5p for main 5.16.1
    already. I would never dare to release such a problematic zero release
    and why should I do if committers also do not care?

    Why do you think are the patchlists in the downstream releases so long?
    And we downstream packagers have even no chance to see what' being voted upon.
    All these discussions should happen on p5p.
  • Father Chrysostomos at Jun 10, 2012 at 11:02 pm

    Craig Berry:
    On Thu, Jun 7, 2012 at 4:16 PM, Reini Urban wrote:
    On Thu, Jun 7, 2012 at 2:36 PM, Todd Rinaldo wrote:
    As I understand it, one has to have a commit bit in order to see the voting system for cherry pick candidates into maintenance branches, Is that true? If not, how can I see this information?
    It's a good question. I don't know the answer, but ISTR both Jesse
    and Ricardo asking for folks to find ways to make it more public,
    scalable, robust, etc. As Leon has now posted, the source code is
    there to be fiddled with.

    But remember, cherrymaint was a nifty, quick hack to work around the
    absence of a maint pumpking. More visibility would be a very good
    thing, but there would need to be other changes as well in order to
    manage additional input. IMO, we need not only a way for more people
    to say "please get patch 123 into the next release," but also (and
    even more importantly), a way for people to say, "Assign patch 123 to
    me; I'll test it on versions I, J, K of compiler/platforms X, Y, Z in
    configurations A, B, C, and while I'm there I'll read and understand
    what it's doing and determine whether it preserves binary
    compatibility, and has adequate test coverage, and I'll step through
    it in gdb to see if it's really doing what we're saying it's doing,
    and slam it against valgrind to see what breaks, and I'll weigh the
    benefits against the risks for putting it in maint, etc."
    And being able to vote on behalf of someone else who said +1 in a e-mail would be good. And seeing who voted for whom, etc.

    That sounds like a complicated piece of software. But it also sounds a lot like a text file in Porting/.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedJun 7, '12 at 7:36p
activeJun 11, '12 at 10:06a
posts16
users9
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase