[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
From: |
Yann Droneaud |
Subject: |
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal |
Date: |
Mon, 08 Nov 2004 12:19:56 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Thomas Lord <address@hidden> writes:
> > From: Yann Droneaud <address@hidden>
>
> > what's going to be fixed, to be merged, to be improved in for the
> > candidate release ?
>
> See the recent annoucement.
>
It was posted while i wrote the message ;)
> > It's very unclear on what's your working on
>
> I asked Matthew to identify the most critical fixes from the 1.2.2
> branch that could be merged quickly and to start with those.
>
> Matthew has announced (not where you've seen, apparently) that he's
> also dredging the 1.2.2 line to pull out other change and prepare them
> for the GNU mainline.
>
But there's no formal list or description of what will be fixed or merged.
> > Since James stopped his work of integrator, I feel the development has
> > stalled,
>
> James sustained a very high merge rate while, to put mildly,
> neglecting to cooperate with the GNU release process. Thus, his high
> merge rate is not so high after all when you consider that a few weeks
> of his work has to be gone over a second time by Jivera.
>
> It's slightly ridiculous to say much of anything at all about the
> current change rate of the mainline. After the big crisis, we've had
> a new person in the integrator / release manager seat for just a
> couple of weeks now. In that time he has produced a test candidate
> with the very highest priority changes. So far, to me, in the context
> of recent history: I think the change rate is finally starting to look
> good again. But really, we won't know for sure for another month or
> two, at which point we can look back and see how we've been doing.
>
But to my point of view, the "change rate" is not visible.
>
> > Jivera seems to work on his own, there's little discussion on
> > the mailing list, no report, no announcement of what's being commited,
> > merged, etc ... it's hard to see what's will be done.
>
> There's not a lot to discuss, just now: it's pretty much deterministic
> that he has to pick a certain subset of the changes from 1.2.2 and
> that's likely to keep him mostly busy through the first two test
> candidate releases.
>
> During that time, if someone has some change they want to make a
> priority, I suggest that they make their case on the -dev list.
>
> But you're right about one thing: there isn't enough transparency in
> the project right now. Yours isn't the only feedback I've gotten
> asking for more and, in fact, making the project /systamatically/ more
> transparent is something I've been working on tools for very hard
> recently.
>
I'm not asking for "systamatically". I'm just asking for more
information,
>
> > We switch from bazaar to cathedral model
>
> I'm not sure that that's even a meaningful statement.
I tried to mean that James was merging patches as they come, without
following a development schedule of what features to add, merge,
improve: it's bazaar style.
As i read the rel-src-mgt.txt, we need some sort of roadmap for the new
features (bug fix are generally not candidate for that ;) :
this is catheadraal style.
> The only real
> change for submitters here is that we ask them to prepare submission
> branches rather than ad hoc merges. Here is a reason why:
>
> 1. Ad hoc merges take a lot of time and effort to process by hand,
> and even then, it is an error-prone process. Submission
> branch merges, on the other hand, are very easy to quickly process
> and get to a state where they can be reviewed. Thus, part of the
> change here is to help protect the scalability of the integration
> manager: to ask contributors to take on the error-prone grunt work
> by preparing a clean submission branch instead of just tossing an
> ad hoc merge request over the wall.
>
> 2. There are many ancillary benefits (for everyone, including good
> forks) from having the mainline working with submission branches.
> Such submission branches are, in effect, revisioned changesets and
> so if modifications to a change are needed before it can be merged,
> a submission branch provides a convenient mechanism for that.
> Submission branches also provide a clean and regular mechanism for
> cherry-picking from the queue of mainline contributions.
>
> The few people who are making noises about the horribleness of the
> patch log pruning that submission branches involve haven't, afaict,
> thought the matter through: yes, we need an "=merges" file to support
> cherry-picking of submission branches but, given that file, the
> log pruning is harmless (doesn't harm smart merging) and beneficial
> (manages the log directory size sanely).
>
> It's a project /without/ a log pruning policy that you'd really want
> to watch out for. Can you imagine, for example, an arch-based linux
> kernel project that simply retained /every/ patch log file from
> anywhere in the ancestry of the kernel? For a long time I thought
> projects should just prune based on time ("that log is so old we
> probably don't need it anymore") but the pruning based on submission
> branches is much, much cleaner.
>
I'm not discussing the new "process" for merge. No need to justify.
I have the same concerns than other reluctant about log pruning,
but i'm waiting to see what will happen. I acknoledge the patch log must be
pruned to scale, but arch protocol doesn't have currently the support
for it. (So the pruning happen a little too early since it doesn"t have
the infrastructure now).
>
>
> > The new model did not encourage contribution because I don't see how
> > to submit them for review, when they will be merged, and if they will
> > ever be merged (the need for copyright assigment: i have no real problem
> > with it, but tell me how to complete it, and if it's legal to do it in
> > my country: you nead to ease the process and give information if you
> > want people to do it quickly)
>
So, no one have solution, information for me ?
Can i submit my "automatic changelog fix" without the copyright
assignment done ?
I thnik it's just a trivial fix i think:
http://bugs.gnuarch.org/cgi-bin/mergereport.cgi?merge=57
Like this one, but i created a new file :
http://bugs.gnuarch.org/cgi-bin/mergereport.cgi?merge=56
> > So what are the goals for the next days, weeks, months ?
>
> Hopefully I've answered for the next .5 - 1.5 months: namely continue
> to catch up with what seems valuable from 1.2.2, making that available
> as testing candidates.
>
> > What have to be done, what's need to be improved ?
>
> /That/ topic is something I'll be addressing over the rest of this
> week and the beginning of next, I hope. I've been madly hacking
> to set up an infrastructure for nicely maintaining such "managerial
> state" of the project.
>
Nice to read.
(I'm quite late in reading gnu-arch messages).
>
> > (PS: don't pay attention to my english, correct if you can,
> > ask me if you really don't understand ;)
>
> (It seems fine. I didn't notice that you weren't a native speaker
> until I read your PS.)
>
And for the new message ? ;)
Regards
--
Yann Droneaud <address@hidden> +33 6 88 40 82 43
<address@hidden> <address@hidden> <address@hidden>
http://droneaud.com/ http://meuh.org/ http://meuh.tuxfamily.org/
1024D/BEA43321 5D91 B5B0 5137 B8FE 6882 FE19 CAA0 6F05 BEA4 3321
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, (continued)
Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Matthew Dempsky, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Yann Droneaud, 2004/11/01
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Thomas Lord, 2004/11/02
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal,
Yann Droneaud <=
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Matthew Dempsky, 2004/11/11
- Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal, Stephen J. Turnbull, 2004/11/12