[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]
Re: git, process and progress (was Re: dump.c cleanup)

From: Nicholas Clark <nick@ccl4.org>
To: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Cc: chromatic <chromatic@wgz.org>, perl5-porters@perl.org
Date: Tue, 26 May 2009 20:34:50 +0100
Message-ID: <20090526193450.GR2941@plum.flirble.org>
On Tue, May 26, 2009 at 08:14:25AM +0200, Rafael Garcia-Suarez wrote:
> 2009/5/26 chromatic <chromatic@wgz.org>:
> > Do I recall correctly that this process stalled when someone suggested "It's
> > just too hard to generate a perldelta, so thanks, but no thanks!"  (Once upon
> > a time a pumpking decided that patches without test cases and documentation
> > changes were unacceptable, so it seems like a small leap to require delta
> > patches too.)
> 
> With git, we now more or less require commit messages too.
> (git format-patch is preferred over git diff.) A good commit message is
> often the basis for a perldelta entry.

True

But not all commits are perldelta entries. (Many need to be edited out)
And some perldelta entries are 3 or 4 fold expansions on the commit message,
and there's nothing wrong with the commit message, because it's terse, to the
point, but assumes a lot of context which then needs to be written out
explicitly in perldelta.

> > As long as producing a release relies on someone spending a day a week
> > cherrypicking patches from an unstable branch into a stable branch, I believe
> > that no one who knows how to make a release will ever have time to write up
> > what it takes to make a release (let alone what it will take to make a release
> > parallelizable and trivial), and no one who doesn't already know how to make a
> > release will learn how to make a release.  Cart, egg, horse, chicken.

Having a binary compatible branch, and a "free-for-all" branch makes
maintaining binary compatibility much easier. For some value of "easier"
probably actually spelled "possible at all", given that it becomes possible
to review patches after the event to work out whether they are compatible
with the stability goals of the maintenance branch.

> > My concrete suggestions are:
> >
> > 0) Release 5.10.1 and 5.11.0 concurrently
> 
> Very good idea.

Heck, what's wrong with releasing 5.11.0 *before* then?

Several people have said "what's stopping us?" and really, for blead, all it
is is "write the perldelta". At which point they evaporate.

> > 3) Enable smoking of branches ready to merge to trunk
> 
> That would go with 1.

re-ordered, because I think that that's a prerequisite of 1

> > 1) Require all feature work to occur in branches
> 
> Good idea -- but at some point you'll have to merge in trunk, and that's
> usually where new features get more broadly tested, and where bugs are
> discovered. (Just look at my recent smartmatch branch -- the few
> recent changes were made in trunk, after the merge.)
> 
> > 2) Declare and enforce trunk stability (no more "bleadperl" from which someone
> > cherrypicks stable commits)
> 
> I don't think that's a good idea. Nicholas already explained that at
> length.
> 
> However the situation can be improved -- for example bug fixes could go
> in a branch off the 5.10 release point, and that branch be merged in
> maint-5.10 and trunk afterwards.

I'm not sure on that one. We have had things that are bug fixes where we're
not sure of the stability issues for a while. Or where they've caused subtle
bugs. (There's one I'm thinking of involving resizing the stack before doing
a require, which seemed like the "right" thing, but caused C undefined
behaviour elsewhere when an exception was thrown:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-11/msg00511.html

)

> Also, I think there is a possibility to write a tool to help in the
> cherry-picking -- at least to distribute the knowledge of what has been
> already reviewed for inclusion in maint. There are many solutions.

Seems useful.


> > 5) Write a release manager guide
> 
> Good idea, embryos exist in Porting/, they need to be updated a bit I
> think.
> 
> > 6) Recruit likely release managers for the next several releases
> 
> Volunteers anyone ?

This works for blead. I'm not convinced that it solves the real bottlenecks
for any "stable" release, be it 5.10.x or 5.12.0. Specifically, the analogous
Parrot document says

    A couple of weeks in advance: Ask people to run C<make fulltest> and
    report (and hopefully fix!) any problems they find. Check in with
    language project leads for release blockers, to allow time to fix them.

( https://svn.parrot.org/parrot/trunk/docs/project/release_manager_guide.pod )


I think that for a stable release the question "is it ready" is more like:

    Does CPAN pass?

which comes down to:

    for each module that fails its regression tests on $current
      did it fail identically on $previous?
      if yes, "SEP"
      else work out why it failed (a bisect is useful for this)

    attempt to group failure causes

    for each failure cause
      is that a regression?
      if yes, figure out how to fix it
        (more code? revert the code that broke it)
      else
        (presumably) it's relying on something un-or-under-documented
        should the existing behaviour stay?
          yes - goto "regression"
          no - note it in perldelta as a significant bugfix
          (also, try to inform the module's author)


and the decisions involved in that are never going to be scriptable.

You wrote:

: Several people who volunteered last year to manage a releases from a checklist 
: of tasks they could work through to produce a release.  What happened?  What 
:  happened to that checklist?  Was it a bad idea?  Did no one have time to write 
: it?  Did the volunteers all say "No, thank you!" privately?

and my view is that the above set of steps are

1: What sets Perl apart from certain less well managed projects

   (eg PHP, where IIRC 5.0.8 broke something to do with arrays, and the final
    conclusion of the PHP maintainers was "oh, well, it stays. fix your
    scripts")
   (eg Ruby, where 1.9.0 broke Rails. I infer that the Ruby maintainers don't
    test prominent Ruby code to be aware of the problem, but worse, the Rails
    maintainers don't bother to test upcoming Ruby releases)

2: Not a set of tasks that can be "worked through"

3: Not the work that really needs spreading out

[people volunteered in error after Gabor misread the message I wrote about what
*did* need doing, and wrongly assumed that it meant a scriptable task list]


The set of tasks that can be "scripted" for Perl 5, analogous to steps 2-11 in
https://svn.parrot.org/parrot/trunk/docs/project/release_manager_guide.pod
for 5.8.9 at least were roughly:

0: so you think you have a source control in a state that won't break CPAN,
   at least not in "surprising" ways.

1: As there are no regular smokes (yet - please fix?) find out about the state
   of VMS. If it's bad, think again.

2: Re-read the perldelta to try to find any embarrassing typos

3: Run Porting/makemeta

4: [used to be run autodoc.pl, but I eliminated that]

5: [used to be run pod/buildtoc, but I eliminated that]

6: update module corelist, but we need to fix that
   [it has been holding perforce revisions for releases, but we can't know
    hashes in advance for git. We need to agree a plan to move to git tags]

7: [update changes, but Dave has eliminated that]

8: update patchlevel.h to remove all local patches

9: make tarball with Porting/makerel

10: copy tarball to some other machine x 2 [or more - IRC is good for this]

11: check that ./Configure -des && make all test works in one place

12: check that ./Configure ... && make all test_harness install works
    [that's likely something that needs fixing in the Parrot checklist -
     there's no step to check that it installs, that the installed parrot runs,
     or that the installed parrot can be used to build a third-party language
     such as Rakudo or Pynie]


for 5.8.x I did this:

13: bootstrap the CPAN client on the clean install

14: install CPANPLUS

15: bootstrap the CPANPLUS client

16: install an XS module

17: if this is good, commit this.
    sit, and wait.

18: do the smoke tests pass (particularly Win32)

19: if yes, upload it to PAUSE. This is the point of no return

20: mail p5p to announce it, with a quote I prepared earlier

21: wait 24 hours or so

22: post the announcement to use.perl



And, I repeat, doing the above is actually *quite fun*, after all the stress
and hard work of dealing with the issues of "is it releasable?" The above
steps appear to be analogous to the steps in the Parrot release guide.

So, I was never looking for anyone to do that for me.

> > 7) Set a release schedule tied to the calendar, not the state of any feature
> >
> > 8) Follow the release schedule
> 
> I shall be clear here: those two points are completely impossible and
> unrealistic -- at least as long as no-one's time is bought to make the
> pumpking job. You just can't make previsions based on the availability
> of a resource you don't control -- here, the time.

In particular, I can't see how 7 and 8 work given either

1: it is discovered that trunk contains a regression from the previous stable
   release
2: it doesn't look like a bug fix will arrive before the release date

or worse

1: it is discovered that a bug fix added in the previous release *also*
   introduces a regression
2: it doesn't look like a bug fix will arrive before the release date


The choices are
a: reverting the change that fixes the bug? [introduces a second regression]
b: do nothing [keeps a regression]
c: defer the release until quality is restored.


My view was always that it was more important to avoid creating regressions,
than to fix (non security) bugs. Better the bugs you know. Specifically,
because modules on CPAN *have* to work round existing bugs, whatever you do
in a new release. So keeping the same bugs doesn't increase the workload on
CPAN authors.

Whereas fixing one bug but introducing another

1: increases the complexity for CPAN authors
2: provides a disinsentive for end users to upgrade from their current version.
   If they know that the next version, meant to be compatible, isn't quite,
   why should they risk upgrading?

It's not good having a reputation for shipping slightly buggy releases.
Because if you do you end up with more spread of installed versions than you
would otherwise, and you have a harder time getting people to do the right
thing ["upgrade to fix this bug", versus "suffer it and hack round it" or
"we want the old version, with just the bug fixes".

This happens. An ActiveState employee has told me that firms want
"DBI version $this, and then just the bug fixes from the later versions".
I'm aware that firms wanting to install Linux want (say) 2.4.18 plus all the
bug fixes. But it has to be 2.4.18. (Consultant's solution was to take the
current version sources, and change the reported version number, because it
was actually the best solution for the customer's real need.)]


I think that 5.8.9 was generally successful in the "don't introduce regressions"
stakes. I believe that there are only two known so far:

1: suidperl doesn't work. no-one who needed it tested it. They get what they
   deserve
2: there's a regression with assigning format references

Nicholas Clark
Follow-Ups from:: "H.Merijn Brand" <h.m.brand@xs4all.nl>
David Golden <xdaveg@gmail.com>
References to:: Jim Cromie <jim.cromie@gmail.com>
David Golden <xdaveg@gmail.com>
Nicholas Clark <nick@ccl4.org>
chromatic <chromatic@wgz.org>
Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]