Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal

[Thomas Lord]

    > 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'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.

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


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


    > We switch from bazaar to cathedral model

I'm not sure that that's even a meaningful statement.   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.



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


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

-t