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 :-(.
