[development] Splitting up patches

[Neil Drumm]

Angela Byron wrote:
> I think a sensible rule of thumb would be "split up patches where you 
> can," for the reasons you specify. But there are some places where it 
> either just doesn't make sense, or worse makes things more difficult, 
> and it would be great if core committers could keep that in mind when 
> making these requests.

Like all things, you have to be pragmatic. Feel free to push back if you 
think any request is unreasonable. (I do sometimes play devil's advocate 
to see how important some things are. Ber loves when I poke at removing 
various fields.)

> I think another thing that would help *a lot* is to be given some more 
> kind of concrete guidelines about what exactly CAN get in after the code 
> freeze. It seems logical that relatively "minor" stuff like improved 
> wording changes, some spiffy graphics to spruce things up, and so forth 
> would be ok. "Usability" is a broad term, though:

I simply won't look at something labeled as a feature. If I think 
someone is mislabeling, I'll change it.

Usability changes are often not simple rearrangements of items on a page 
(thats okay while frozen). Usability changes are perfectly justified in 
going all the way to the underlying database structure and APIs if thats 
what is needed (probably not okay while frozen).

I'm not aware of any existing rules that are written down, but it does 
roughly correspond to issues that are bugs and simple tasks are okay to 
commit.

> * Would a new default core theme be considered "usability?" (It 
> certainly makes life easier for users, and for site designers who need a 
> good Drupal CSS theme to start from.)
> etc.

I do not want to see some "base" theme get into core. We have default 
themeable functions that should see the markup improvements instead.

Is anyone actually working on this stuff, admin or default theme, with 
the intention of getting it in core?

> Then I think we would be able to draw better conclusions on where to 
> focus our reviewing efforts, and we'd feel more at ease splitting up 
> major patches, because we'd all be kind of on the same page as to what 
> needed to get done by the 1st.

How I deal with this is:
- Realize that everything will never be done.
- And the list of things to do will always be about the same length.
- There is always another release.
So the point is to make things improve, not finish them.

> If you got through all that, congrats and thanks for reading. ;)

Good rant.

-- 
Neil Drumm
http://delocalizedham.com/