Re: Status of kha/experimental

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 09, 2007 at 10:10:12PM +0100, Catalin Marinas wrote:
> On 07/10/2007, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
> > On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
> >
> > > How stable is the kha/experimental branch? Since there are more and
> > > more bugs added to the tracking system, I'll have to start looking
> > > at them before a 0.14 release. Is it worth merging the
> > > kha/experimental now or we better wait for after 0.14?
> >
> > The idea is that experimental contains changes that need testing, but
> > may not yet be ready for your master. (They are generally safe,
> > though; I run StGit from my experimental branch at work, for example.)
> > When I decide that they are ready, I move them to safe. If there are
> > any patches you feel should be in safe rather than experimental, just
> > ask. Or you could just take them directly from experimental without
> > asking, of course. :-)
> 
> OK. My plan is to merge kha/safe and have a look at what seems safer
> to merge from kha/experimental. Fix bugs (and freeze the current
> features). Release 0.14. Merge kha/experimental entirely post 0.14 and
> test/stabilize it over couple of months. How does this sound?

Sounds like a good time to bring back my refactoring patches from the
hydra patchset.  I have not addressed yet the remarks that were voiced
at that time, and the hydra patch itself has not been completed, and
in fact the refactorings touch so many parts of the code that I can't
envision mantaining them outside the tree (in fact, I left them bitrot
for that very reason).  If there is no other remarks than those
already posted as replies to the patchset, maybe we could consider
merging them soon after kha/experimental ?

That would require that I update them, but I'm not sure Karl would
want them in kha/experimental, since virtually any other patch causes
a conflict...  The best situation would be that there would be a code
freeze at some time, during which I could update those patches without
too much perturbations, but that may be asking a lot :)

The ideal situation would be if we would make diffcore and merge aware
of a (de)indentation type of change.  That's something I have felt the
need for since ages, but I'm unfortunately not going to find the time
to implement that anytime soon :)

Best regards,
-- 
Yann
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux